Spring + GWT or Spring vs GWT

Question

Background

I am in the middle of developing a web application using GWT, Java, and EclipseLink. Each of those selections are choices I have made to implement this program. GWT is the only choice where there is not a firm grasp as to what it is exactly compared to something like Spring. Right now I use GWT widgets to implement the client and GWT RequestFactory to implement the server-client communication of entities from EclipseLink.

Views

So I view GWT as primarily a library of widgets with a simple framework for server-client communication. This is much the same way I view Spring, a library of widgets with a much more advanced and complex framework for controlling server-client communications - with the possibility that it does not implement AJAX as conveniently as GWT does.

So with these in mind, I view GWT as a stepping-stone to understanding and eventually working with Spring. However, Google-ing on this topic again, I've come across several topics like this one and that one that seem to go against the original notions of what Spring is, and what that means for GWT.

The Questions

1. Is there a misconception about the views on GWT and Spring? If so, some brief guiding points about that would be much appreciated!
2. What would be the counter-part to GWT widgets in the Spring Framework?
3. What would be the counter-part to GWT RequestFactory in the Spring Framework?

Answer 1

It really depends on how you plan to use GWT in your application.

GWT is best used for single host page web-applications.
That means that all the flow synchronization and business logic is done on the client side using GWT.
This is where GWT really shines (see here for more details).

However if you go down this road, you will end up with basically two distinct applications. You will have a frontend developed with GWT and a backend using Spring for example. Your backend (Spring or whatever you use) will only act as a "data storage" providing you with data that you are going to display in your GWT frontend. So your will probably not using any of the Spring MVC's functionality.

Of course you can also use Spring MVC and use GWT only to add web 2.0ish functionality to your site, but for that use case I would recommend to rather use jQuery, Closure or other javascript frameworks.

To your questions:

Is there a misconception about the views on GWT and Spring? If so, some brief guiding points about that would be much appreciated!

If you use GWT as it is intended (single host page web-applications) then you won't use the MVC part of Spring. You can still use authorization, authentication, ORM and many other components of the Spring framework, however GWT handles all the views.
Spring acts more or less only as a data storage for your GWT frontend app. It's like having two distinct and separate apps that are connected through a communication protocol (RequestFactory, REST, RPC, etc).

What would be the counter-part to GWT widgets in the Spring Framework?

There is no real counter-part to GWT widgets in the Spring Framework (maybe to some extends JSF). Spring is all about the server-side so all the views there are created on the server side. Whereas GWT is all about client side.

What would be the counter-part to GWT RequestFactory in the Spring Framework

RequestFactory is the communication protocol between your frontend app (GWT) and your backend app (Spring). When you use Spring MVC you don't need any communication protocol as the views are generated on the server side where you already have the data.

Answer 2

GWT is not a widgets library, but an entire framework to produce full web applications which runs in client instead of server side. The basic difference is that spring (MVC pattern) is server focused, so it connects to the ddbb, executes the business logic and produces the view to send to the client, since GWT (MVP pattern) runs the presenter in the browser which produces the view, and it just connects to the server to get results or objects (remote methods).

Said that, depending on your GWT app, you could need more or less logic in the server side, and other elements like ddbb, spring, etc.

The decision about when to choose GWT or any other framework depends on whether you need a rich (desktop like) application running in browser.

Logically you can mix GWT and spring in any level of complexity, but the logical way is to give spring the responsibility of the data model and its business logic, and GWT doing the rest.

The best way to learn this combination is exploring a small project generated with Spring-roo. It can create an entire project with all set for maven, spring, gwt, mvp and rf. Just install roo 1.2.2 and run this set of commands in the roo console:

project --topLevelPackage com.project.contacts
persistence setup --provider ECLIPSELINK --database HYPERSONIC_PERSISTENT
database properties set --key database.url --value jdbc:hsqldb:/var/tmp/contacts.db
entity jpa --class com.project.contacts.domain.Contact --testAutomatically
field string name --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string surname --notNull --sizeMin 1 --sizeMax 30 --class ~.domain.Contact
field string phone --notNull --sizeMin 1 --sizeMax 15 --class ~.domain.Contact
web gwt setup
web gwt all --proxyPackage ~.client.proxy --requestPackage ~.client.request
quit

Then execute

mvn gwt:run

The main problem I see with roo is that it uses 'aspectj' to update managed classed when you modify the model, but you could remove the roo dependency and aspectj files using eclipse once your project was set up.

Answer 3

Check out Objectify for your backend. Way simpler.