Great I will take a look. This area of GWT is moving pretty fast. A couple the projects mentioned by David are new to us since we have started development including gwt-platform. We like gwt-dispatch but we are crazy about the number for little libraries we are using for the full stack. gwt-platform looks like a option to bring those together.
On Fri, Oct 1, 2010 at 10:31 AM, PhilBeaudoin <[email protected]>wrote: > All the samples that come with gwt-platform uses UI Binder (and > @UiHandler), check the samples repo: > http://code.google.com/p/gwt-platform/source/browse?repo=samples > > A larger example is PuzzleBazar: > http://code.google.com/p/puzzlebazar/ > > They all use gin. > > Cheers, > > Philippe > > > On Sep 30, 2:33 pm, Jason Hatton <[email protected]> wrote: > > 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 > > <[email protected]>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 <[email protected]> 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 <[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 ? > > > > > - 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 <[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%[email protected]><google-web-toolkit%2Bunsubs > [email protected]><google-web-toolkit%2Bunsubs > > > [email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]><google-web-toolkit%252Bu > [email protected]><google-web-toolkit%252Bu > > > [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%[email protected]><google-web-toolkit%2Bunsubs > [email protected]><google-web-toolkit%2Bunsubs > > > [email protected]> > > > > > <google-web-toolkit%[email protected]<google-web-toolkit%[email protected]><google-web-toolkit%252Bu > [email protected]><google-web-toolkit%252Bu > > > [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%[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%[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%[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.
