On Sep 30, 12:22 pm, David <[email protected]> wrote: > Any other feedback about this ? > What's odd is that we are still asking this very same question after > several years of existence of both frameworks, don't you think ? > > So, we have : > - GWT SL > - Spring4GWT > - Gwt-dispatch > - gwt-spring > > (My) Questions are : > - which of them are still maintained ?
gwt-dispatch is still maintained > - which of them do provide a compatibility with the latest versions of > GWT and Spring ? Gwt-dispatch works with 2.1M3 and Spring 3. It also works with spring 2.5.6 and previous versions of GWT (1.6 i think is the earliest version) > - which of them are non intrusive ? I find gwt-dispatch to be FAR superior to standard Service/ ServiceAsync calls, as it allows you to make each method call its own class, no editing of the web.xml/applicationContext file for each rpc created. > > David > > On 20 sep, 23:41, Jason Hatton <[email protected]> wrote: > > > > > Hey lalit, > > > I will take a look at this further this was and example of how to implement > > Spring on a previous version and is basically the servlet example class I > > posted earlier. I will take a look at the newer version of gwt-dispatch to > > see what else has been included. We were waiting on upgrading but this > > peaks my interested on upgrading sooner. WebApplication context is just > > Spring's way of bootstrapping an application context in a web container. > > What that class does is grab the application context wires in the > > DispatchServlet so POJOS can be injected in to all the classes it supports. > > Definitely it is in the spring-web jar but it appears that is the only > > Spring feature gwt-dispatch project takes advantage of. If you take a look > > at the ActionHandler and base dispatch classes you don't see any other > > Springy stuff. > > > Gwt-dispatch helps us to avoid having to code the separate interfaces. We > > just code actions, action handlers, and result objects. All the dispatch > > traffic routes through the one GWT-RPC service that gwt-dispatch implements. > > All the async workings have to be there but, we get to work on valuable > > object interactions and avoid ceremonial grunt work which always makes > > coding more fun. > > > Later, > > Jas > > > On Fri, Sep 17, 2010 at 1:12 AM, lalit <[email protected]> wrote: > > > Hi Jason, > > > > I agree that both the approaches are same. But I still have a feeling > > > that gwtDispatch uses Spring MVC infra to do its job. The code that > > > you have posted above has WebApplicationContext. Also I looked into > > > gwtDispatch code and it seems it is using Spring MVC infra. The code I > > > looked into is here > > > >http://code.google.com/p/gwt-dispatch/source/browse/src/main/java/net... > > > > Another thing you mentioned in your mail that you do not have to code > > > two interfaces which looked interesting. If possible can you elaborate > > > on that? We would like to incorporate that in our approach also if > > > possible. > > > > thanks, > > > > On Sep 16, 7:15 pm, Jason Hatton <[email protected]> wrote: > > > > Lalit we are not using Spring MVC. We am using gwt-dispatch and have > > > > extended that project's dispatch servlet to get the Spring integration. > > > We > > > > then added a custom annotation to pick up the appropriate dispatch > > > > action > > > > handler for a particular GWT-RPC on the server side. All of our GWT-RPC > > > > calls go through this servlet so we avoid the overhead and code bloat of > > > > having to create the standard GWT-RPC interfaces for every new service > > > call > > > > we want to implement. I looked over your example again and they are > > > pretty > > > > similar. I like your integration approach with Spring but I prefer > > > service > > > > call handling because we don't have to code the two separate RPC > > > interfaces, > > > > i.e. the Service and ServiceAsync for every service we want to > > > implement. > > > > We just create an new dispatch handler apply an annotation to it and we > > > are > > > > off and running. > > > > > On Wed, Sep 15, 2010 at 11:33 PM, lalit <[email protected]> wrote: > > > > > Deepak - I have used the following structure > > > > > SpringApplicationContext, SpringGwtRemoteServiceServlet , > > > > > PersonServiceImpl go into the server side code. > > > > > The interfaces PersonService and PersonServiceAsync become part of > > > > > GWT client side code. > > > > > > Regarding wsdl files consumption see the section on JAX-WS here > > > > >http://www.lalitbhatt.com/tiki-index.php?page=JAX-WSespeciallJAX-WS > > > > > client side section. This approach uses JAX-WS approach. > > > > > > For data binding you can use JAXB. The details can be seen here > > > > >http://www.lalitbhatt.com/tiki-index.php?page=JAXB. JAX-WS anyway uses > > > > > it internally. > > > > > > Also just a disclaimer, the approach I took is as per Spring4GWT > > > > > project so it's there idea. > > > > > > Jason- I looked into your approach and conceptually they look similar > > > > > in terms of that you are redirecting the request to Spring MVC > > > > > infrastructure. IMHO the aprroach I took as per Sping4GWT is better as > > > > > one does not have to carry the SpringMVC baggage. > > > > > > -- > > > > > 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%2Bunsubs > > > > > [email protected]><google-web-toolkit%2Bunsubs > > > [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]<google-web-toolkit%2Bunsubs > > > [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.
