I've been looking into this for the past few days. RequestFactory seems like it could be a solution. It would solve other problems too, such as being able to selectively expose the fields of entity classes. Some of our entity classes would not translate over to GWT.
However, my initial impression of RF is that it is unappealing. It reminds me of things like Corba and early versions of J2EE with entity (EntityProxy) and session (ValueProxy) beans. With j2ee there was also the notion of container managed persistence, which we see RF moving towards. In our case, we already have a wonderful data model in POJO. Why create all these extra layers of software just to find a way to display some portion of the model in a browser? Seems like overkill and over-complication. Plus our app is more than just CRUD and I don't see RF making things easier in that case. Another option is to simply try and move as much of our model into the GWT client as possible. In my first attempt to port over an existing web app, I end up having lots of RPC calls that simply operate on objects in the session (and never hit the database). If these objects could be made to work on the client side, then much of the work could be moved there too while minimizing stuff sent over the wire. The session variables would go away, along with RPC calls to access them. In general, the client would maintain the state, which is a huge advantage. RPC calls could then be very similar to web service calls that actually do work. I'm looking into this latter option. If that doesn't work out, then I will have to consider RF. One possibility is to use RF with simply ValueProxy's. This kind of reminds me of how early j2ee developers largely avoided EntityBeans in favor of SessionBeans! Mike On Dec 14, 11:47 pm, -sowdri- <[email protected]> wrote: > Mike, this is exactly where DTO pattern has to be used. > > 1. Just create a DTO which encapsulated all the objects required at > startup. > 2. And expose a new service, which would do all the sequential calls on > the server and construct the dto and return. > > Remember, a server call is the most costliest operation in terms of time > for the client. Coupled that with making it sequential, (adding to the > startup time) its going to take ages). > > Note: RF btw has request batching :) > > Hope this helps! -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
