Thomas, Thanks for your response. Here are a few follow ups: 1) The idea of forcing separation between client and server code so that GWT can generate client code is perhaps too restrictive. We have a lot of getter methods with intelligence or decoration of the returned value. Currently, we know this will work on the client and server side. But with RF, I have to move that logic elsewhere. Keeping the entities common and forcing them to be GWT actually has a nice side-effect - it forces you to keep your entities clear of useless dependencies.
2) Its nice that a command line validator is provided, but that just means more build time checks for something that Java could natively do. So the advantages of incremental compilation via Eclipse/IDEA etc are gone. Also, there will be additional delays before this trickles down to maven plugins and other artifacts. Note: With the command pattern, my async interface only has one method - Result execute(Action a); that is generified so I never have to worry about it (and it is burried in common-library). Actions and Results get associated by simply being defined as spring beans and everything works like magic. On Tue, Dec 14, 2010 at 9:18 AM, Daniel Simons <[email protected]> wrote: > 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]. >> 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. > -- 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.
