Just my thought on the subject, At the start of using GWT we also wondered about why there was no support for continations in GWT and that these Async and Sync interfaces would cause us a lot of grieve. But it all worked out very well since we are actually generating the sync and async interfaces from anotations on session beans. Some people might loath session beans but since EJB3 they are quite easy to write with not much redundancy.
If you want your code base technology agnostic then you don't want to just blindly extend the GWT rpc servlets in all your business code, you rather have POJO code that you call from the GWT server side layer. david On Tue, Aug 4, 2009 at 7:17 AM, John Patterson<[email protected]> wrote: > On 4 Aug 2009, at 09:26, Rob Heittman wrote: > > I do just have to say ... I don't use RPC at my shop. It is a > bit forced, as the underlying RESTful plumbing of the web doesn't map > tightly onto the RPC paradigm. GWT puts RPC style coding in reach, > but I still prefer to opt for pure REST. I think we get better > results. The evidence is anecdotal and qualitative, but weighty. > > The protocol you use is a related but separate topic to the flow of control. > When using RPC (XML-RPC and SOAP) in the past I found it worked great and saved a lot of complicated > URL manipulation. With enough "plumbing" you end up with your own RPC > system, no? > > The provided JSON, DOM and HTTP modules, our own JSNI-based XML > NativeDocument, and Restlet-GWT, among others, give plenty of ways to > front end anything from Rails to Restlet to Lift with GWT applications. > > Horses for courses. > > I am ... not enthused ... about masking the reality of HTTP even > further with simulated continuations in RPC, when I think what's > already there encourages non-optimal (albeit sort of easy) application > design. > > REST frameworks also masks the reality of HTTP. In fact that is one of the > benefits touted by Restlet. > > "Easy" is not the main benefit. It is less error prone and easier to > maintain. It moves some of the complexity from each client into the > framework. I have already seen people on the lists talking about problems > keeping the remote and asnyc interfaces. There is even an issue asking for > the Eclipse plugin to automatically track the two of them. That is a sure > sign that something is questionable about the API > > My vote would be the opposite -- a renewed focus on the basics, to > better document and encourage the simple and efficient RESTful > practices GWT allows with many diverse server apps. > > That isn't really "opposite" - just a different area of functionality. Both > could exist. Also, good documentation would be needed to say "this remote > call could take a long time". But that is not a hard concept to grasp. > > These aren't > hacky in the least -- and the Async patterns in GWT are quite lovely > compared to writing XmlHttpRequest async code directly in JS. > > I bet you were into the lovely EJB artifacts too? Ha ha this is strangely > reminiscent. > Again, I don't think that making the developer more mindful is a good enough > reason to make the API more complicated and client code harder to maintain. > But if there are technical reasons why continuations generated by the > compiler in JavaScript would not work.... well that is a different story! > > John > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
