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%2Bunsubs > > > > > > > > [email protected]><google-web-toolkit%2Bunsubs > > [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%2Bunsubs > > > > > > [email protected]><google-web-toolkit%2Bunsubs > > [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%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.
