Hello David & al,
The SL is also actively maintained - releases are not that frequent
anymore though (there's not much to do) because of the high maturity grade.
David 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]>
.
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.
