So far I built most of my UI and logic in QML with JavaScript without touching the C++. But now I need to make a RESTFul API call, based upon the examples I saw so far I must write the call code in C++ then "some how" (Am still figuring out that part) get it in the QML/JavaScript world....
Can't i make the API call etc completely etc in QML/JavaScript?
I am not an expert in REST but in theory if you could write the call in JavaScript running in a browser, you should be able to make the the same call using very similar JavaScript in QML/JS.
Having said that one of the things you want to do to maintain the responsiveness of your application is not run any time consuming routines on the event thread. Ensuring this is the case is quite easy in C++, I'm nos sure you could do that as easily in JS.
Finally it is relatively easy to get the results back to JavaScript world is quite easy. Qt and Cascades has a rich data modeling component set. QVariantList and QVariantMap types map into JS arrays.
Related
I understand that both xsodata and xsjs are used for exposing data but why there are two ways? Which one should one use and how the use of xsodata is different from xsjs data.?
Good Question, I will try to give you a little overview. I will describe three SAPUI5 ways of backend implementation.
XSODATA
Let's assume, you have something like a Checklist. You may want to add items to your list, edit or delete them and - obvious - you want to display them. These simple tasks are called CRUD (create, read, update, delete) operations. These Operations are the simplest way of dealing with data. There are no real "hard" queries to get work done and you may operate on very less JOIN's. This can be easyly done with XSODATA. It's a simple REST-Interface.
XSJS
Okay, you have your checklist, but you want to log every single entry, or do analysis or something not-so-easy with it. This is, where XSJS comes into play. With XSJS you have a better control (and much more work needs to be done) of your data. But keep in mind, that you need to code every single step. XSJS is not a real interface, but it's a sapui5 way of handling data, like you would do in any other vanilla-programming-language without a framework.
Node.JS / custom backend
Another, newly (2017) introduced way of handling data at sapui5 is the usage of Node.JS. Node.JS let you write your own RESTful API (node.js is much more powerful than that, but this information must be enough for now). Node.JS is something like the intersection between XSODATA and XSJS: you are able to use a RESTful API (implemented by yourself) with 100% datacontrol. I don't want to go too much into detail, but Node.JS is for advanced applications the state-of-the-art at early '17.
Conclusion
What you might use really depends on your application itself. Personally, I think the best way to start is with XSODATA. If you can't solve certain tasks with only oData, use XSJS for those single cases. In a real-world application with tons of data and complex queries, you might consider Node.JS as your backend-wizard.
useful informations:
OData vs XSJS in SAP Hana Development
https://archive.sap.com/discussions/thread/3688095
http://saphanatutorial.com/sap-hana-xsjs-service/
https://blogs.sap.com/2015/12/08/sap-hana-sps-11-new-developer-features-nodejs/
https://nodejs.org/en/
I am developing a GWT app using GWTP (Model-View-Presenter) that is deployed to GAE. Persistence will be done using Google Cloud SQL.
I am not sure what to use to send data to the database (persistence) and request data: GWT RequestFactory or GWTP Actions. Are they equivalent? What are benefits of each one for this scenario?
Thanks
I wouldn't use Request factory as it stands right now. Even for CRUD it's much more complicated to us than GWTP Actions.
RF is a great and powerful tool, but it's a little bit over engineered and working with complex data can be really difficult with all the "frozen" states problems that you will end up having. The real problems comes while using the editors with nested structures. You'll have problems saving the second level of proxies and even more the third level. Using editors with nested structures is a lot more easier with the SimpleBeanEditorDriver since you don't have to deal with the nasty frozen state for each level of nested objects.
For a simple object graph with simple CRUD support, RF is perfect, but as soon as you go to more complicated structures, brace yourself, it won't be easy to handle. Once you become a RF expert, it become a really powerful tool, but it still require more work than GWTP Actions to accomplish the same thing.
For server side security using RF, I've used AoP. On the other side, you could use action handlers, but even by using action handlers, there's some case where AoP on a service call is more appropriate.
For client side batching and caching... that's something that is really hard to achieve with RF. The documentation is unclear and dealing with frozen state within the cache is a nightmare. With GWTP-Action, there's already a simple cache implementation that you can use.
For a data-oriented app (CRUD), you should definitely use RF because it has been designed for that purpose. Now if your app is more action-oriented and these actions does not involve much data, it’s better to use the Command pattern. But nothing prevents you from using both in your app.
RequestFactory only.
Everything you need is there. If you just want to send a basic message you just call a method with whatever parameters you want.
Problem with Actions is that they're a lot more verbose than RF semantics...
Only thing you don't get with RF is the ability to use ClientHandlers...
I googled around and learned that Lift encourages view-first development, lazy loading of entities, perfectly interactive wizards and validators, built-in comet etc.
It seems to cover the territory of Backbone.js and its client-side (MVC) interactive rendering brethren (and also some interactive features of jQuery).
Does Lift make a lot of Javascript needed for (two-way) interactive web apps redundant, by being mostly self-contained? Where would I still need to apply Javascript libraries?
Lift uses jQuery (or YUI if you want) to do the client side interactions (Ajax, comet). But you don't see that most of the time. You can of course write JavaScript on the client side and call those functions from your server code using Lift.
If you really want to use frameworks like Backbone.js you can do that, and then use Lift as a REST backend.
But in general, if you want your application to perform some comet style updates or Ajax, Using Lift will save you a lot of time and headaches. And if you want full control over the JavaScript, you can get that too.
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);
I would like to make a small program that scrapes information from a 3rd-party GWT-enabled website. Is it possible to somehow call this RPC directly? What would I need to reverse-engineer to do this (i.e. hopefully not the entire low-level protocol).
I am hoping I could somehow just call this from within my own server-side GWT or Servlet app.
It is possible... but you would have to go through their code to understand how the serialization/deserialization works.
Classes of interest are
RPC.java
ClientSerializationStreamWriter -> ServerSerializationStreamReader are the classes involved in making a GWT request.
ServerSerializationStreamWriter -> ClientSerializationStreamReader are the classes involved in creating and interpreting a response.
I am trying out a similar thing as an academic project, and I will add more information if I can decipher these classes.
I'm pretty sure GWT makes it difficult to do cross-site requests, for the sake of security.
Any solution you come up with will probably be hacky (and not flexible to future changes), and since you're presumably doing it without the consent of the site in question, probably a bad idea to begin with.
Is there some reason you can't ask the site to publish their data using a REST API?