GWT and Spring - with Spring Web MVC or without it?
434 views
Skip to first unread message
ezamur
Jun 8, 2010, 11:32:26 AM6/8/10
to Google Web Toolkit
Hi all...
I am new to GWT - had some contact with it earlier but not enough to
say I am confident with it.
My task is to investigate this technology and pair it with Spring
framework. There are a lot of tutorials explaining how this can be
done, but what is bothering me is I can't decide which approach to
choose. For example, I've seen one using Spring's MVC (like this one:
http://technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-its-step/),
but also other where integration is done without it (e.g.
http://code.google.com/p/gwt-spring-starter-app/)
I am afraid to miss something important by choosing one of these
approaches and possibly lose some of Web MVC functionalities that
might be needed later or end up in dead end street using it.
I would be grateful if anyone explained me what are the pros and cons
of these approaches from practical point of view - is there a need for
DispatcherServlet and Controllers while having GWT and its RPC
mechanism.
Thanks in advance.
I am new to GWT - had some contact with it earlier but not enough to
say I am confident with it.
My task is to investigate this technology and pair it with Spring
framework. There are a lot of tutorials explaining how this can be
done, but what is bothering me is I can't decide which approach to
choose. For example, I've seen one using Spring's MVC (like this one:
http://technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-its-step/),
but also other where integration is done without it (e.g.
http://code.google.com/p/gwt-spring-starter-app/)
I am afraid to miss something important by choosing one of these
approaches and possibly lose some of Web MVC functionalities that
might be needed later or end up in dead end street using it.
I would be grateful if anyone explained me what are the pros and cons
of these approaches from practical point of view - is there a need for
DispatcherServlet and Controllers while having GWT and its RPC
mechanism.
Thanks in advance.
Brian Reilly
Jun 10, 2010, 9:26:53 AM6/10/10
to Google Web Toolkit
I've had good luck with the second (non-invasive) approach. A coworker
of mine implemented the first (using Spring MVC) approach and it did
work for the most part. However, we aren't otherwise using Spring MVC
and don't have any broad expertise in it, so I was initially confused
when looking at it. Specifically, I didn't know about the relationship
between the servlet name and the "-servlet.xml" file, the contents of
which require some learning to understand (i.e.,
SimpleUrlHandlerMapping and its "mappings" property). I also didn't
like the additional wrapper GwtRpcController around the actual
service; it seems like an unnecessary layer. I think this setup keeps
you from having to extend RemoteServiceServlet, but you still have to
worry about GWT serialization of parameters and return values so I
don't see it as a big gain. Also, the proxy means that you lose
getThreadLocalRequest unless you add code to the GwtRpcController to
forward it to your service.
I like the non-invasive approach because it keeps the setup of the GWT-
RPC servlet exactly as explained in the GWT documentation. Your spring-
configured services don't change either. You just gain the ability to
inject those services into your GWT-RPC remote servlets.
I think it comes down to where you're coming from. If you already use
and like Spring MVC, you'll probably prefer the first approach. (I
hope someone with that perspective also responds to describe the
benefits of that setup.) If you like GWT and just need to integrate
with your spring-configured services, you'll probably prefer the
second approach.
-Brian
On Jun 8, 11:32 am, ezamur <eza...@gmail.com> wrote:
> Hi all...
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> choose. For example, I've seen one using Spring's MVC (like this one:http://technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-...),
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
of mine implemented the first (using Spring MVC) approach and it did
work for the most part. However, we aren't otherwise using Spring MVC
and don't have any broad expertise in it, so I was initially confused
when looking at it. Specifically, I didn't know about the relationship
between the servlet name and the "-servlet.xml" file, the contents of
which require some learning to understand (i.e.,
SimpleUrlHandlerMapping and its "mappings" property). I also didn't
like the additional wrapper GwtRpcController around the actual
service; it seems like an unnecessary layer. I think this setup keeps
you from having to extend RemoteServiceServlet, but you still have to
worry about GWT serialization of parameters and return values so I
don't see it as a big gain. Also, the proxy means that you lose
getThreadLocalRequest unless you add code to the GwtRpcController to
forward it to your service.
I like the non-invasive approach because it keeps the setup of the GWT-
RPC servlet exactly as explained in the GWT documentation. Your spring-
configured services don't change either. You just gain the ability to
inject those services into your GWT-RPC remote servlets.
I think it comes down to where you're coming from. If you already use
and like Spring MVC, you'll probably prefer the first approach. (I
hope someone with that perspective also responds to describe the
benefits of that setup.) If you like GWT and just need to integrate
with your spring-configured services, you'll probably prefer the
second approach.
-Brian
On Jun 8, 11:32 am, ezamur <eza...@gmail.com> wrote:
> Hi all...
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
Richard Allen
Jun 11, 2010, 9:44:33 AM6/11/10
to Google Web Toolkit
There is also the GWT Server Library from the GWT Widget Library
project: http://gwt-widget.sourceforge.net/
You should also check out the support for GWT that is now built into
Spring Roo. If you already use (or want to use) the technologies that
Spring Roo builds in, like JPA, then Roo will get you running fast
with a solid architecture that uses best practices:
http://www.springsource.org/roo
http://blog.springsource.com/2010/05/19/spring-roo-1-1-0-m1-released/
http://blog.springsource.com/2010/06/02/using-springsource-tool-suite-2-3-3-m1-with-roo-and-gwt/
I don't think there is one right answer to your question. How you use
Spring with GWT depends on your project and your team's preferences.
However, it is quite useful using Spring MVC (or some other Java web
framework) with GWT because GWT doesn't provide much server-side
facilities. In a large project, you are likely to need some static web
pages that do not use GWT, and Spring MVC makes that easy (among many
other things). Additionally, we have used Spring MVC controllers for
file upload and download, and to serve up resources from the
classpath.
I also believe it is very useful to avoid having your actual service
implementation extend from GWT's RemoteServiceServlet. Spring MVC
allows your controllers to be implemented as POJOs, and most Spring-
GWT integration libraries strive to allow you to use GWT RPC while
still implementing your services as POJOs. Some benefits to this
approach are the ease of unit testing POJOs and no dependence on GWT
libraries in your services.
Hope that helps,
-Richard
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
project: http://gwt-widget.sourceforge.net/
You should also check out the support for GWT that is now built into
Spring Roo. If you already use (or want to use) the technologies that
Spring Roo builds in, like JPA, then Roo will get you running fast
with a solid architecture that uses best practices:
http://www.springsource.org/roo
http://blog.springsource.com/2010/05/19/spring-roo-1-1-0-m1-released/
http://blog.springsource.com/2010/06/02/using-springsource-tool-suite-2-3-3-m1-with-roo-and-gwt/
I don't think there is one right answer to your question. How you use
Spring with GWT depends on your project and your team's preferences.
However, it is quite useful using Spring MVC (or some other Java web
framework) with GWT because GWT doesn't provide much server-side
facilities. In a large project, you are likely to need some static web
pages that do not use GWT, and Spring MVC makes that easy (among many
other things). Additionally, we have used Spring MVC controllers for
file upload and download, and to serve up resources from the
classpath.
I also believe it is very useful to avoid having your actual service
implementation extend from GWT's RemoteServiceServlet. Spring MVC
allows your controllers to be implemented as POJOs, and most Spring-
GWT integration libraries strive to allow you to use GWT RPC while
still implementing your services as POJOs. Some benefits to this
approach are the ease of unit testing POJOs and no dependence on GWT
libraries in your services.
Hope that helps,
-Richard
> Hi all...
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> choose. For example, I've seen one using Spring's MVC (like this one:http://technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-...),
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
Stefan Bachert
Jun 13, 2010, 7:59:40 AM6/13/10
to Google Web Toolkit
Hi,
Spring MVC does not fit to GWT at all.
GWT considers the browser to be a thin/rich client, and the server to
be the data source/model
Spring MVC considers the browser to be an ultra thin client (something
like an x-server), and considers the "server" to be a fat client,
where presentation, business logic and persistence live.
Spring MVC is an artefact of the pre-AJAX-era.
Use GWT for real application (RIA) and use Spring MVC for hyperlinked
documents.
In a complex website you may switch between real applications and
hyperlinked documents, so you will find both in one site.
But it makes NO sense to drive GWT with Spring MVC.
When you look at Spring Roo and its GWT support, it comes without
Spring MVC (Spring Roo can generate Spring MVC controller but without
GWT). It is "either or"
Stefan Bachert
http://gwtworld.de
On Jun 8, 5:32 pm, ezamur <eza...@gmail.com> wrote:
> Hi all...
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> choose. For example, I've seen one using Spring's MVC (like this one:http://technophiliac.wordpress.com/2008/08/24/giving-gwt-a-spring-in-...),
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
Spring MVC does not fit to GWT at all.
GWT considers the browser to be a thin/rich client, and the server to
be the data source/model
Spring MVC considers the browser to be an ultra thin client (something
like an x-server), and considers the "server" to be a fat client,
where presentation, business logic and persistence live.
Spring MVC is an artefact of the pre-AJAX-era.
Use GWT for real application (RIA) and use Spring MVC for hyperlinked
documents.
In a complex website you may switch between real applications and
hyperlinked documents, so you will find both in one site.
But it makes NO sense to drive GWT with Spring MVC.
When you look at Spring Roo and its GWT support, it comes without
Spring MVC (Spring Roo can generate Spring MVC controller but without
GWT). It is "either or"
Stefan Bachert
http://gwtworld.de
On Jun 8, 5:32 pm, ezamur <eza...@gmail.com> wrote:
> Hi all...
>
> I am new to GWT - had some contact with it earlier but not enough to
> say I am confident with it.
>
> My task is to investigate this technology and pair it with Spring
> framework. There are a lot of tutorials explaining how this can be
> done, but what is bothering me is I can't decide which approach to
> but also other where integration is done without it (e.g.http://code.google.com/p/gwt-spring-starter-app/)
Jan Ehrhardt
Jun 13, 2010, 11:52:16 AM6/13/10
to google-we...@googlegroups.com
If you want to use GWT RPC for client server communication, there is no need for Spring Web MVC. If you want to provide a RESTful API and use it for GWT too, Spring Web MVC is a good choice for realizing RESTful APIs.
Regards
Jan Ehrhardt
Regards
Jan Ehrhardt
2010/6/13 Stefan Bachert <stefan...@yahoo.de>
--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
George Georgovassilis
Jun 14, 2010, 4:39:32 AM6/14/10
to Google Web Toolkit
I'll go with Stefan here.
MVC implies that the server handles much of the view - with a GWT
application the server is reduced to a glorified DAO. All you really
need is integrate services from the backend into the frontend. What we
really missing is something like RMI for the browser - GWT's RPC is as
good as it gests for this purpose and and libraries like the GWT-SL
allow you to directly publish Spring managed POJOs as services over
RPC into the client.
On Jun 13, 1:59 pm, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> Spring MVC does not fit to GWT at all.
>
> GWT considers the browser to be a thin/rich client, and the server to
> be the data source/model
>
> Spring MVC considers the browser to be an ultra thin client (something
> like an x-server), and considers the "server" to be a fat client,
> where presentation, business logic and persistence live.
> Spring MVC is an artefact of the pre-AJAX-era.
>
> Use GWT for real application (RIA) and use Spring MVC for hyperlinked
> documents.
>
> In a complex website you may switch between real applications and
> hyperlinked documents, so you will find both in one site.
> But it makes NO sense to drive GWT with Spring MVC.
>
> When you look at Spring Roo and its GWT support, it comes without
> Spring MVC (Spring Roo can generate Spring MVC controller but without
> GWT). It is "either or"
>
> Stefan Bacherthttp://gwtworld.de
MVC implies that the server handles much of the view - with a GWT
application the server is reduced to a glorified DAO. All you really
need is integrate services from the backend into the frontend. What we
really missing is something like RMI for the browser - GWT's RPC is as
good as it gests for this purpose and and libraries like the GWT-SL
allow you to directly publish Spring managed POJOs as services over
RPC into the client.
On Jun 13, 1:59 pm, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> Spring MVC does not fit to GWT at all.
>
> GWT considers the browser to be a thin/rich client, and the server to
> be the data source/model
>
> Spring MVC considers the browser to be an ultra thin client (something
> like an x-server), and considers the "server" to be a fat client,
> where presentation, business logic and persistence live.
> Spring MVC is an artefact of the pre-AJAX-era.
>
> Use GWT for real application (RIA) and use Spring MVC for hyperlinked
> documents.
>
> In a complex website you may switch between real applications and
> hyperlinked documents, so you will find both in one site.
> But it makes NO sense to drive GWT with Spring MVC.
>
> When you look at Spring Roo and its GWT support, it comes without
> Spring MVC (Spring Roo can generate Spring MVC controller but without
> GWT). It is "either or"
>
Richard Allen
Jun 15, 2010, 2:54:02 PM6/15/10
to Google Web Toolkit
For operations like file upload which cannot be done with Ajax, GWT
provides no server-side facilities. With Spring MVC, you can easily
wire up a Spring Controller that handles the file upload request that
a GWT client submits to.
See: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-multipart
Yes, Spring MVC is a page-based framework with both server-side and
client-side facilities, and GWT is a component-based mostly client-
side only framework that was designed for web applications that
execute in a single page, such as Gmail, Google Maps, and Google Wave.
However, even an app like Gmail has a login page that is separate from
the actual application which submits a form post, then redirects the
browser to a separate page that loads the application. Spring MVC is
well suited for serving pages like that login page and handling the
form post.
Additionally, there is great benefit derived from using Spring Core
for dependency injection and AOP of your server-side code. All serious
Java web applications that I have worked on have significantly more
server-side code than client-side code.
-Richard
On Jun 13, 7:59 am, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> Spring MVC does not fit to GWT at all.
>
> GWT considers the browser to be a thin/rich client, and the server to
> be the data source/model
>
> Spring MVC considers the browser to be an ultra thin client (something
> like an x-server), and considers the "server" to be a fat client,
> where presentation, business logic and persistence live.
> Spring MVC is an artefact of the pre-AJAX-era.
>
> Use GWT for real application (RIA) and use Spring MVC for hyperlinked
> documents.
>
> In a complex website you may switch between real applications and
> hyperlinked documents, so you will find both in one site.
> But it makes NO sense to drive GWT with Spring MVC.
>
> When you look at Spring Roo and its GWT support, it comes without
> Spring MVC (Spring Roo can generate Spring MVC controller but without
> GWT). It is "either or"
>
> Stefan Bacherthttp://gwtworld.de
provides no server-side facilities. With Spring MVC, you can easily
wire up a Spring Controller that handles the file upload request that
a GWT client submits to.
See: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-multipart
Yes, Spring MVC is a page-based framework with both server-side and
client-side facilities, and GWT is a component-based mostly client-
side only framework that was designed for web applications that
execute in a single page, such as Gmail, Google Maps, and Google Wave.
However, even an app like Gmail has a login page that is separate from
the actual application which submits a form post, then redirects the
browser to a separate page that loads the application. Spring MVC is
well suited for serving pages like that login page and handling the
form post.
Additionally, there is great benefit derived from using Spring Core
for dependency injection and AOP of your server-side code. All serious
Java web applications that I have worked on have significantly more
server-side code than client-side code.
-Richard
On Jun 13, 7:59 am, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi,
>
> Spring MVC does not fit to GWT at all.
>
> GWT considers the browser to be a thin/rich client, and the server to
> be the data source/model
>
> Spring MVC considers the browser to be an ultra thin client (something
> like an x-server), and considers the "server" to be a fat client,
> where presentation, business logic and persistence live.
> Spring MVC is an artefact of the pre-AJAX-era.
>
> Use GWT for real application (RIA) and use Spring MVC for hyperlinked
> documents.
>
> In a complex website you may switch between real applications and
> hyperlinked documents, so you will find both in one site.
> But it makes NO sense to drive GWT with Spring MVC.
>
> When you look at Spring Roo and its GWT support, it comes without
> Spring MVC (Spring Roo can generate Spring MVC controller but without
> GWT). It is "either or"
>
Reply all
Reply to author
Forward
0 new messages