Excellent! Thank you for the information. I still however have to wait until support for DAOs & embeded objects is implemented in the MVP framework (I am using Objectify for my ORM as well ass a DAO) before I can cut over.
I am also concerned about the apparent reliance on Roo to generate the boilerplate code. It appears that Google is very much behind this combo. It isn't that I have anything against Roo, DI or generated code for that matter but I would have preferred a leaner solution. Applications targeting App Engine already experience enough latency on start-up and I am afraid that DI will just make matters worse; and as I still haven't been able to figure out how to get Roo and Objectify to work together my apprehension is that much more intensified. But I am open minder. We developers have to be :) and as such I would very much like to be proven wrong on all these counts. Again, thank you for the information on RequestFactory. Jeff This is indeed great news. On Sat, Oct 30, 2010 at 5:13 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On 30 oct, 16:44, Jeff Schwartz <jefftschwa...@gmail.com> wrote: > > I haven't read up in detail on the new RequestFactory implementation > except > > for the information I've read here on the group. I gather from what I've > > read then that RequestFactory is totally data specific and its only > > intention is to persist any data that has been changed on the client back > to > > the server. It therefore seems, for example, that if it were required for > > security reasons, for instance, to validate that the request to the > server > > is made with a valid session id and the session was still active that > > RequestFactory would not be the api to use and that instead the older > > RemoteService api would be the one to use, correct? > > No. > > The first thing the RequestFactoryServlet does is to (paraphrasing the > comment in the code) "check that user is logged in before > proceeding" (this is done by "getting" a UserInformation instance, > which has access to the servlet request through > RequestFactoryServlet.getThreadLocalRequest() so you're free to do > whatever checking you want; the actual implementation is given by the > userInfoClass servlet init parameter; see the Expenses sample for an > example using AppEngine's UserService), and return a 401 HTTP response > if it's not the case (which you can trap on the client-side). > > On the client-side, RequestFactory uses by default a > DefaultRequestTransport, which you can extend (or even replace, I > think you could use WebSocket or Comet or whatever if you liked) to > send the "session id" in the request payload (for instance); similar > to the RpcRequestBuilder for GWT-RPC. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Jeff -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
