I have a project that utilizes RequestFactory and works in 2.1 but not in 2.1.1. Is there an example out there making use of the 2.1.1 RequestFactory improvements?
On Tue, Dec 14, 2010 at 8:05 AM, Thomas Broyer <[email protected]> wrote: > > > On Tuesday, December 14, 2010 1:14:30 PM UTC+1, kabram wrote: >> >> We have a significant sized app built using GWT 2.0 and we have simple >> Command pattern based abstraction for sending entities back and forth >> between the server and client. The new RequestFactory while >> interesting seems to require too much "scaffolding" interfaces and >> classes. >> >> - Why should I create duplicate proxy interfaces? Can't I just reuse the >> entity? >> > No. > One of the goal of RF is to completely separate server code from client > code, so that a) you can use whatever you want on the server side (including > directly in your entities) and b) the client-side can be optimized at will > because it's enterily generated by GWT. > See https://wave.google.com/wave/waveref/googlewave.com/w+WU4iAICkI > >> - The requirement that the service implement the RequestContext >> interface but not really - leads to poor code maintainability as one >> cannot simply rename methods taking advantage of IDE features. >> > See > http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/requestfactory/server/RequestFactoryInterfaceValidator.html > You can use it as a command-line tool to validate your client-side > interface against your server-side implementations. > I believe the next version of the Google Plugin for Eclipse (or at least a > future version) will integrate it, just like it validates the sync and async > interfaces of GWT-RPC (which suffer from the exact same issue). > > >> - The 2.1 idea of have DAO methods in entities? >> > Not necessarily. But then methods *have* to be static. > >> What was the thinking here? >> > AFAIK, Spring Roo generating static methods on entities, similar to Rails' > ActiveRecord and the like (but Ruby allows monkey patching which makes > testing and mocks possible, something that a statically typed language like > Java cannot do) > >> Seems 2.1.1 is addressing it. >> > > Yes! > > >> - The requirement to have findEntity() on the entity itself - leads to >> very poor separation of concerns. >> > > See above, but 2.1.1 addresses that one too. > > >> - The requirement to have getVersion() - well, what if I don't want my >> entity to be versionable? Why am I being forced here? This is another >> example of forcing the framework user to write code to make the >> framework do its work. >> > > Versions are necessary for the "update" mechanism. The constraint was > initially relaxed in 2.1.1 but re-added last week: > http://code.google.com/p/google-web-toolkit/source/detail?r=9381 > > >> - The requirement to explicitly edit() an entity (again, just so the >> framework can figure out changes) is burdensome. >> > It makes you intents clear. Your proxies are there so you can communicate > with the server, so edit()ing a proxy is kind of like creating a "request > builder". You then add an "invocation" (service method call) and fire() the > request. And everything is "magically" replayed on the server. > > >> My concern now is that other libraries (e.g. Ext GWT) will adopt this >> forcing theRequestFactory upon everyone. How far does 2.1.1 go in >> alleviating the above? I think I'm going to stick with the simple >> GWT-RPC. Hopefully that is not going away anytime soon. >> > The new Google Groups is using GWT-RPC, so I believe it's there to stay! > > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- 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.
