I took a brief look at gwt-platform. I didn't see examples where the GWT 2.0 UI binding capability is used. We are successfully using this with Gin. Do you know of examples that include the use of UI Binder?
On Thu, Sep 30, 2010 at 2:35 PM, PhilBeaudoin <philippe.beaud...@gmail.com>wrote: > Many gwt-platform [1] users have also successfully integrated its > dispatch module with Spring. The next version (0.5), planned in a > month or so, will add built-in support for Spring. It will also make > it easy and seamless to switch the backing service for your various > server actions. (Some can use GWT rpc's, some can use REST, etc.) The > latter is already available in the trunk, although it's likely to > change before the release. > > Cheers, > > Philippe > > [1] http://gwtplatform.com > > > On Sep 30, 10:59 am, Jason Hatton <jashat...@gmail.com> wrote: > > I honestly can't weigh in on all of these framesworks. Gwt-dispatch is > > maintained and is pretty light weight and extensible which we have > extended > > ourselves to add Spring support. Looks like the latest version adds that > in > > for anyone needing it. We have also extended it to lessen the burden of > > creating new GWT-RPC end points. We use an annotation based approach > that > > basically adds a new Gwt-Dispatch action handler which equates to a new > > GWT-RPC endpoint. Our current production code base is using Spring 3.x > and > > Gwt-Dispatch 1.0.0. > > > > > > > > On Thu, Sep 30, 2010 at 12:22 PM, David <dmartin....@gmail.com> 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 ? > > > - which of them do provide a compatibility with the latest versions of > > > GWT and Spring ? > > > - which of them are non intrusive ? > > > > > 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-tool...@googlegroups.com. > > > > > > > To unsubscribe from this group, send email to > > > > > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs > cr...@googlegroups.com> > > > <google-web-toolkit%2bunsubscr...@googlegroups.com<google-web-toolkit%252bunsubscr...@googlegroups.com><google-web-toolkit%252Bu > nsubscr...@googlegroups.com> > > > ><google-web-toolkit%2Bunsubs > > > > > cr...@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-tool...@googlegroups.com. > > > > > To unsubscribe from this group, send email to > > > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs > cr...@googlegroups.com> > > > <google-web-toolkit%2bunsubscr...@googlegroups.com<google-web-toolkit%252bunsubscr...@googlegroups.com><google-web-toolkit%252Bu > nsubscr...@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-tool...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com><google-web-toolkit%2Bunsubs > cr...@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-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@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-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.