> 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 <jashat...@gmail.com> 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 <lalit.bh...@gmail.com> 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 <jashat...@gmail.com> 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 <lalit.bh...@gmail.com> 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
> > > google-web-toolkit@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
> > > > > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@googlegroups.com><google-web-toolkit%2Bunsubs
> > > cribe@googlegroups.com>
> > > > > .
> > > > > 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 google-web-toolkit@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@googlegroups.com>
> > > .
> > > 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment