I've just started learning Google Web Toolkit and finished writing the Stock Watcher tutorial app.
Is my thinking correct that if one wants to persist a business object (like a Stock) using JDO and send it back and forth to/from the client over RPC then one has to create two separate classes for that object: One with the JDO annotations for persisting it on the server and another which is serialisable and used over RPC?
I notice the Stock Watcher has separate classes and I can theorise why:
Otherwise the gwt compiler would try
to generate javascript for everything
the persisted class referenced like
JDO and com.google.blah.users.User, etc
Also there may be logic on the server-side
class which doesn't apply to the client
and vice-versa.
I just want to make sure I'm understanding this correctly. I don't want to have to create two versions of all my business object classes which I want to use over RPC if I don't have to.
The short answer is: you don't need to create duplicate classes.
I recommend that you take a look from the following google groups discussion on the gwt-contributors list:
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/3c768d8d33bfb1dc/5a38aa812c0ac52b
Here is an interesting excerpt:
If this is all you're interested in, I
described a way to make GAE and
GWT-RPC work together "out of the
box". Just declare your entities as:
#PersistenceCapable(identityType =
IdentityType.APPLICATION, detachable
= "false") public class MyPojo implements Serializable { }
and everything will work, but you'll
have to manually deal with
re-attachment when sending objects
from the client back to the server.
You can use this option, and you will not need a mirror (DTO) class.
You can also try gilead (former hibernate4gwt), which takes care of some details within the problems of serializing enhanced objects.
Your assessment is correct. JDO replaces instances of Collections with their own implementations, in order to sniff when the object graph changes, I suppose. These implementations are not known by the GWT compiler, so it will not be able to serialize them. This happens often for classes that are composed of otherwise GWT compliant types, but with JDO annotations, especially if some of the object properties are Collections.
For a detailed explanation and a workaround, check out this pretty influential essay on the topic: http://timepedia.blogspot.com/2009/04/google-appengine-and-gwt-now-marriage.html
I finally found a solution. Don't change your object at all, but for the listing do it this way:
List<YourCustomObject> secureList=(List<YourCustomObject>)pm.newQuery(query).execute();
return new ArrayList<YourCustomObject>(secureList);
The actual problem is not in Serializing the Object... the problem is to Serialize the Collection class which is implemented by Google and is not allowed to Serialize out.
You do not have to create two versions of the domain model.
Here are two tips:
Use a String encoded key, not the Appengine Key class.
pojo = pm.detachCopy(pojo)
...will remove all the JDO enhancements.
You don't have to create separate instances at all, in fact you're better off not doing it. Your JDO objects should be plain POJOs anyway, and should never contain business logic. That's for your business layer, not your persistent objects themselves.
All you need to do is include the source for the annotations you are using and GWT should compile your class just fine. Also, you want to avoid using libraries that GWT can't compile (like things that use reflection, etc.), but in all the projects I've done this has never been a problem.
I think that a better format to send objects through GWT is through JSON. In this case from the server a JSON string would be sent which would then have to be parsed in the client. The advantage is that the final Javascript which is rendered in the browser has a smaller size. thus causing the page to load faster.
Secondly to send objects through GWT, the objects should be serializable. This may not be the case for all objects
Thirdly GWT has inbuilt functions to handle JSON... so no issues on the client end
Related
I am about to start new java project and I consider GWT as my framework for it.
I've checked a lot of articles on the internet (main documentation also) and I am quite confused.
So I ask You:
Can I use jpa Entities to work with DAO, and to be sended over network to client?
I really don't understand the concept of DTO (writing almost the same but more poor class of Model)
If I will about to send Entities over network to client, how to use Serializable Transient annotation to NOT serialize and send methods, parameters of class? Is it even possible?
How all of this will work with Generic Typed Superclass extended by right class implementation?
f.e:
public class GenericModel extends GenericModel<T> {
//some generic code
}
public class RightModel extends GenericModel<RightModel> {
// some right class code
}
the same goes with DAO...
Please help.
I count on Yours experience.
Not that I was an expert at that time but when I started to combine Hibernate (not JPA as such) and GWT, it was a pain.
The reason that you can't just send over Hibernate managed objects (and I guess same counts for JPA, regardless of the underlying technology), is that they contain bytecode-manipulation stuff like javassist. GWT doesn't like this at all, and you can't send those objects over the GWT RPC wire.
Ofcourse also it doesn't make sense: you can't expect your Javascript (client-side) to invoke SQL to lazy-load collections when you invoke a getter on your DAO (because that's what happens server-side with these DAO objects, that's what the javassist magic is doing behind your back).
I'm not sure that even if all collections were eagerly loaded, your objects would be free of javassist stuff, and could be serialized over GWT-RPC. That leaves you with one alternative, which is to have POJO objects tailor-made to contain only those parts (properties/collections) that you need on the client at that moment - the DTO.
Since then a lot has happened in GWT, and I know of something completely different from RPC, which is RequestFactory (see http://www.gwtproject.org/doc/latest/DevGuideRequestFactory.html). I haven't used that myself, but it claims to make it easy to build data-oriented (CRUD) apps with an ORM-like interface on the client. So this may be the way to go if you don't want to build custom classes for wiring RPC.
I need to write a rest client (in Java - using RestEasy) that can consume JSON responses. Regarding the need for the rest client (or wrapping service) to translate the JSON responses to a Java type, I see the following options:
1. map the response to a string and then use JsonParser tools to extract data and build types manually.
2. Use JAXB annotated POJOs - in conjunction with jackson - to automatically bind the json response to an object.
Regarding 2, is it desirable / correct to define an XSD to generate the JAXB annotated POJOs? I can advantages to doing this using, e.g. reuse by an XML client.
Thanks.
I'm a fan of #2.
The reasoning is that your JAXB annotated model objects essentially are the contract for the business/domain logic that you're trying to represent on a transport level, and POJOs obviously give you excellent control over getter/setter validation, and you can control your element names and namespaces with fine granularity.
With that said, I like having an additional "inner" model of POJOs (if necessary, depending on problem complexity/project scope) to isolate the transport layer from the domain objects. Also, you get a nice warm feeling that you're not directly tied to your transport layer if things need to change internally in your business/domain object representation. A co-worker mentioned Dozer, a tool for mapping beans to beans, but I have no direct experience with it to comment further.
I'm not a fan of generating code from XSDs. Often the code is ugly or downright unreadable; and managing change, however subtle or insignificant can introduce unexpected results. Maybe I'm wrong about that but I require good unit-tests on a proven model.
This is based on my personal experience writing a customer-facing SDK with a hairy XML-over-HTTP (we don't call it REST) API. JAXB/Jackson annotated POJOs made it relatively painless. Hope that helps.
I am working on a web application which is being developed using GWT. I am also using OWL ontologies and Jena framework to structure semantic contents in the application.
A simple function in the application would be getting some data from the user and send it to the servers side to be stored as a data graph using the ontology. I suppose one way would be to store the data as java class objects equivalent to the ontology classes and send them using the GWT async communication. To convert OWL classes to java, I used Jastor.
My question is that after the server receives the java class, is it possible to easily convert is to an OWL individual and add it to the data graph, using the functions of Jena and/or Jastor? For instance in the server side interface implementation we call something like this:
Public void StoreUser (User userObj) {
//User: a Jastor created java class. userObj is instantiated using the user data on the client side.
OntModel ontModel = ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM);
//Open the ontology here using inputstream and ontModel.read!
Individual indiv = (Individual) userObj.resource();
//Add the individual to the model here! }
Unfortunately I wasn't able to find any Jena function that can add an existing individual to the model.
Would you suggest another way to pass the ontology data to server side and store it, rather than using Jastor created classes (for instance using an XML file)?
Thanks for your help
There are two parts to the answer. First, an Individual is a sub-class of a Jena Resource, which is definitely something that you can add to a model. However, individual resources, or properties or literals are not stored in a Model. A Model stores only triples, represented as Statement objects in the Java API. So to add some resource to a model, you have to include it in a triple.
In Jena, an individual is defined as a subject of a triple whose predicate is rdf:type and whose object is not one of the built-in language classes. So if you have:
ex:my_car rdf:type ex:Ferrari .
ex:Ferrari rdf:type owl:Class .
(note: this example is entirely fictitious!), then ex:my_car would be an individual, but ex:Ferrari would not (because OWL Class is a built-in type). So, to add your individual to your model, you just need to assert that it is of some type. Since I don't know GWT and don't use Jastor, I can't say whether the type association that is normally part of a Jena Individual is retained after serialization. I suspect not, in which case you'll need to have some other means of determining the type of the individual you want to add, or use a different predicate than rdf:type to add the resource to the the Model.
All that said, personally I probably wouldn't solve your problem this way at all. Typically, when I'm working with client-side representations of server-side RDF, I send just the minimal information (e.g. URI and label) to the client as JSON. If I need any more data on a given resource, I either send it along with the initial JSON serialization, or it's just an Ajax call away. But, as I say, I don't use GWT so that advice may not be of any use to you.
I am struggling with how to understand the correct usage of models. Currently i use the inheritance of Db_Table directly and declare all the business logic there. I know it's not correct way to do this.
One solution would be to use Doctrine ORM, but this requires learning curve and all the current components what i use needs to be rewritten paginator and auth. Also Doctrine1 adds a another dozen classes which need to be loaded.
So the current cleanest implementation what i have seen is to use the Data Mapper classes between the so called model and DbTabel. I haven't yet implemented this as it seems to head writing another ORM. But example could be something this: SQL table User
create class with setters, getters, business logic here /model/User.php
data mapper /model/mapper/UserMapper.php, the funcionality is basically writing all the update, save actions in here.
the data source /model/DbTable/User.php extends the Db_Table_Abstract
Problems are with relationships between other models.
I have found it beneficial to not have my models extend Db_Table, but to use composition instead. That means my model 'has a' Db_Table rather than 'is a' Db_Table.
That way I find it much easier to reference multiple tables in the same model, which is a common requirement. This is enough for a simple project. I am currently developing a more complex application and have used the Data Mapper pattern and have found that it has simplified my code more than I would have believed.
Specifically, I have created a class which provides all access to the database and exposes methods such as getUser() etc.. That way, if the DB changes, or my client wants something daft like storing records in XML or we split the servers or something I only have to rewrite one class.
Again, my models do not extend this class, but have an instance of it assigned as a property during construction.
I would say the 'correct' way depends on the situation. Following the YAGNI and KISS principles, it is not good to over-complicate your model setup unless you really believe that it will benefit you in the long run.
What is the application you are developing? How is your current setup of extending Db_Table holding you back?
I have started developing my own web framework which has been coming along quite nicely. It simplifies and cators for all my specific needs. I have tried many frameworks like struts, struts 2, tapestry, spring and the list goes on. There are 2 big problems I find in all of these frameworks.
The ability to work with specific business logic/rules.
I am a bit of a perfectionist and the entire layout of these frameworks force you to scatter you validation, DAO logic and your form actions. I like to keep things grouped together and not do validation in my Hibernate Objects, Action classes and a separate XML files which causes a load unnecessary processing.
Ok back to my question. Does any one know of possible solutions to populating Objects from a HTTPRequest? I started looking into introspection and reflection, but I would like to see if there might be a better solution for something like this. Example: Object Student has 3 fields eg String Name, Integer age and Calendar DOB. What are the options in populating this object or any other Object from a HTTPrequest?
You could use a similar system to the way objects are sent in json by adding a __type__field that gets sent with each object. That way you know which object to create and introspect.