Is it possible in GWT 2.4+ to disable obfuscation for certain java model classes?
The reason I am asking this question is we use GWT RPC to talk to the server and need to store these objects returned etc in local storage using the Indexed DB API, we are currently using websql api. If GWT obfuscates/renames your properties etc then this renders using the Indexed DB API useless in your code.
Maybe there is a way to ask GWT to replace a property string with the obfuscated version in your Indexed DB api queries?
I could create a whole new java model that uses javascript overlays so these are preserved when GWT compiled and replace GWT RPC with JSON RPC but this would be a lot of work.
Any other ideas would be appreciated!
I also looked at the AutoBean framework which produces nice JSON output of your model interfaces but I don't think has a nice simple javascript representation under the hood.
You can set GWT Compile style attribute to PRETTY or DETAILED. so that GWT will not replace the class, method or variable names. For more information refer this link.
Related
I am developing a new project with spring boot and graphql. I am confused on how to proceed because there are 2 ways to develop it, one is via the graphqls file and Annotation based approach. I prefer Annotation based approach but are they stable. exmaple : https://github.com/leangen/graphql-spqr.
I second AllirionX's answer and just want to add a few details.
Firstly, to answer your question: yes, SPQR has been pretty stable for quite a while now. Many teams are successfully using it in production. The only reason it is still in 0.X versions is the lack of documentation, but an occasional small breaking change in the API does occur.
Secondly, I'd also like to add that going code-first doesn't mean you can't also go contract-first. In fact, I'd argue you should still develop in that style. The only difference is that you get to write your contracts as Java interfaces instead of a new language.
As I highlight in SPQR's README:
Note that developing in the code-first style is still effectively
schema-first, the difference is that you develop your schema not in
yet another language, but in Java, with your IDE, the compiler and all
your tools helping you. Breaking changes to the schema mean the
compilation will fail. No need for linters or other fragile hacks.
So whether the API (as described by the interfaces) changes as the other code changes is entirely up to you. And if you need the SDL for any reason, it can always be generated from the executable schema or the introspection result.
I don't think there is a good or a bad answer to the "how to proceed" question.
There are two different approaches to build your graphql server (with graphl-java, graphql-java-tools, graphql-spqr), and each method has its advantages and inconvenients. All those library propose a springboot starter. Note that I never used graphql-spqr.
Schema first (with graphql-java or graphql-java-tools)
In this approach you first create a SDL file. The graphql library will parse it, and "all" you have to do is wire each graphql type to its data fetcher. The graphql-java-tools can even do the wiring for you.
Advantage
no need to enter into the detail of how the Graphql schema is built server side
you have a nice graphqls schema file that can be read and used by a client, easying the charge of building a graphql client
you actually define your api first (SDL schema): changing the implementation of the api will not require any change client side
Inconvenient
no compile-time check. If something is not wired properly, an exception will be thrown at runtime. But this can be negated by using graphql-java-codegen that will generate for you the java classes and interfaces for your graphql types, unions, queries, enums, etc.
if using graphql-java (no auto wiring), I felt I had to write long boring data fetchers. So I switched to graphql-java-tools.
Code first (with graphql-java or grapqhl-java-tools or graphql-spqr)
The graphql schema is built programmatically (through annotation with graphql-spqr or by building a GraphQLSchema object in graphql-java)
Advantage
compile-time check
no need to maintain both the SDL and the Domain class
Inconvenient
as your schema is generated from your code base, changing your code base will change the api, which might not be great for the clients depending on it.
This is my opinion on those different framework and I would be happy to be shown that I am in the wrong. The ultimate decision depends on your project: the size, if there is an existing code base, etc.
I was wondering if it's possible to get a remote JSON object using lodash, I've searched; however, what I've found is either you can do it in jQuery or purely in JS (of course it can be done using Angular, Backbone.js, etc..) but I haven't found anything related to lodash.
No
Lodash is a library for working with arrays, objects and functions. It has some basic template features and utilities but no features for making web requests.
See XMLHttpRequest:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
You can do a lot without Lodash
https://www.npmjs.com/package/you-dont-need-lodash-underscore
And if you want an AJAX library. Here's the world's smallest:
https://github.com/yanatan16/nanoajax
Good day. I'm still learning GWT so please help me. I'm working on a project - Web Application with GWT on the Client Side. This app has lots of CRUD operations so I'd like to make a model for this. Can anyone suggest a prototype for my CRUD class?
CRUD on this app goes something like this:
When I clicked the Details button in a module, a popup will be shown that allows the user to do CRUD operations. This popup do have the module title, info on the selected item, and the buttons - Edit, New, Delete.
I have already finished building the base GUI for this project but I'm just starting to work on each module. I choose to begin on those module with CRUD operations. So, please help me and give your ideas on this project. Thanks in advance :)
Your question is a little bit general.
You probably have to deal with two questions which can be handled separately:
Communication with the backend.
GUI for CRUD operations
Communication with the backend:
It depends on which kind of backend you are using.
Java-backend:
For Java backends the recommended client-server communication protocol is RequestFactory.
Non-Java-backend: In case you are using a non-java backend (python, PHP, etc) you have to use RequestBuilder using JSON or XML (I would recommend JSON).
For mapping JSON/XML to DTO's and vice verca you can use different methods:
Third party tools like piriti which are based on GWT generators
Javascript Overlay Types (JSO)
GWT Autobean framework (which is used by RequestFactory btw).
GUI for CRUD operations
For mapping your DTOs to your UI and doing the CRUD operations you can do it either:
manually
with the Editor framework
I would recommend to use the Editor framework as it reduces the amount of boilerplate code
to move an object from your object graph to the UI and back.
The Editor framework works well with RequestFactory (RequestFactoryEditorDriver), Autobean (SimpleBeanEditorDriver) and Javascript Overlay Types.
I am developing an GWT application that uses Hibernate for data persistence on the server side. There are Objects like "Customers" with several attributes like Strings, Integers and Dates.
My problem is to get these objects to the Client to display them (and change/create them and send them to the server). But I always get serialization errors when trying to use my own Types. I read books, searched the internet, read source code and tried out samples. I finally "converted" the attributes of my Objects into the fields of an ArrayList, but I think that can't be the way I should go.
I am currently using gwt-2.0.3 with Eclipse.
Looking forward to reading your suggestions!
This problem occurs because hibernate is using its own colections (PersistentSet and similar). You should use DTO pattern or use Gilead. I'd suggest Gilead (earlier known as hibernate4gwt), you have to configure it and your problem should be gone (read their documentation first to know what is the problem and how Gilead solves it).
If your problem is not related with lazy loading/collections, then your objects are not serializable. Make sure that your classes implement Serializable interface and have zero-argument constructors.
In short, how do you transfer semantic data between client and server with GWT and which frameworks do you use? Read on for more details that I've thought about.
For example, using GWT 2.2.0 features like the RequestFactory will bring the constraint to have java beans transferred while the semantic resources are represented as triples and a resource can have a varying set of properties. So the RequestFactory itself cannot be shaped to transfer semantic-driven data easily.
A way to do that would be to use RequestFactory with beans that represent triples. Such bean would have 3 properties: subject, predicate, object. These beans will be transferred to client which will know to query, change their properties and then send them to server. This approach will however need a custom implementation(there are no GWT-based frameworks to represent semantic data on client-side, from what I've searched so far) and that could prove buggy or unoptimized. I've seen this approach in this project: http://code.google.com/p/gwt-odb-ui/ - it used GWT-RPC and implements some classes that represent semantic resources. However, I think it's in an incipient stage so I'm reluctant to copy their model.
Also, I've found that Restlets is a framework that supports the semantic web approach to applications. However, there is no documentation or an example on how to use Restlets with Semantic Web and perhaps with GWT. Also, Restlets is also supporting GWT. Does anyone know if this is a viable solution or not?
Thank you!
Restlet should work quite well for you. It has a GWT edition able to automatically serialize your triple beans. In addition, it also comes with an org.restlet.ext.rdf extension, including a Link class similar to your triple bean idea.
For further documentation, I would suggest the "Restlet in Action" book which covers GWT and the semantic web from a Restlet and REST point of view.