views:

706

answers:

6

GWT is the main reason I'm moving into java for web development. Which java framework will work best with it, while also maximizing code reuse for mundane tasks like form validation, database access, pagination, etc?

Thanks.

+1  A: 

I'm assuming you don't mean web framework since GWT is itself a framework. I would use JSF to handle the application/business logic side. It makes it easy to store and scope beans, and access the DB. For reading the DB, any JPA flavor you like. I've had good expierence with Eclipselink, but now they all implement the same interfaces. Also you might want to look at EJBs in order to throw everything together and inject the JPA you'll need.

Greg
why jsf? are you passing JSON to the front end or are direct service calls being used? Either way, JSF is not needed.
mainly to create and properly scope managed beans on a per session/request/application instance
Greg
+3  A: 

Spring is the obvious one you should be using. GWT has its own RPC controller framework so I can't really think what you would need a Web application framework (like JSF) for.

JPA is a reasonable choice on several fronts but it has problems too.

For one thing, its potentially an issue sending JPA objects to the client. GWT (up to 1.5 at least) enforces a pretty strict directory structure so you'd have to put your entities under the GWT source tree. That aside, serializing (JSON usually) JPA entities to and from the client is potentially problematic.

JPA entities are fairly rigid objects that map almost one-to-one to your tables. That doesn't tend to be how you use data in a presentation layer however. Direct SQL will allow you to pick and choose which data you do and don't want, tailored specifically for that page. So JPA entities will typically have lots of fields you're not interested in and shouldn't serialize (particularly collections of one-to-many relationships).

Now that aspect of SQL--tailoring it to the page--is often cited as an advantage of entities: your code doesn't end up littered with one-use value objects. Thing is, you still end up with the same thing in gWT+JPA but instead of being in the persistence layer or the business layer you end up with them in the presentation layer. Now you might call that an advantage. I call it six of one, half a dozen of the other.

I actually think Ibatis is a far better fit to the GWT application model than JPA for the reason that you are using direct SQL, objects tailored for your purpose and those objects can be used all the way from the database to the client. Now this concept may horrify the layering zealots that are quite common in Java land but remember layering is a means to an end not an end in itself. Use it if it helps you. Don't if it doesn't.

But Spring is the absolute must in this stack.

I'll also refer you to Why isn’t Google Web Toolkit more popular? and Using an ORM or plain SQL?.

cletus
You don't have to put your JPA POJOs under the GWT source tree, you import them as you do any other external class and make sure you have the source for the JPA annotations in your compiler classpath.
rustyshelf
+3  A: 

If you are developing more application like sites instead of page based sites, I would recommend having a look at the Open Source framework Vaadin. This is server-driven framework which uses GWT on the client side for rendering the frontend, but also automatically handles and keeps sensitive business logic on the server side. This adds some security and you don't have to worry about client<->server traffic (if you don't want to), but can focus on implementing the server side logic in whatever way you prefer. Biggest plus is that you really don't have to code anything else that Java. It is also fairly easy to implement own new GWT components to the framework.

Disclaimer: Yes, I work for IT Mill developing Vaadin, but having a look hasn't hurt anyone yet, has it?

Jonas G
+1  A: 

Ow these responses are hurting my eyes. JSF if your a masochist or Spring if your clinically insane ;)

If your using the built in GWT RPC then you don't need a web framework, you simply use the RPC mechanism to talk to your server. For the back end database and business logic you just use standard JPA Session Beans and POJOs. It's an extremely light, easy to use and supported stack without any headaches. If you're going to be doing forms outside of GWT then make sure you do yourself a favour and check out Stripes as well.

In ASCII Graphix:

Database


JPA Session Beans & POJOs


Web Tier to handle routing between GWT and EJB layer


GWT running as javascript in the browser, making use of all the POJOs you defined in the EJB layer

rustyshelf
+1  A: 

Hi
Now i am using GWT+Struts+Spring+Hibernate
It is better to use json data exchange instead of using GWT webservice.
For that we can separate the logic and the presentation.

Edwin Tai
A: 

Hi,

I use GWT mainly for internal systems but find all I need is a well organised codebase, PAC pattern and Hibernate. Does what I need very nicely.

I started out trying to use tools like dozer to serialise beans across client-server but quickly found it unnecessary. If you need a collection of bars on foo, then pull down list aka getBars(foo). You need to save foo - RPC it up to save(). Keep it simple, pull down what you need, post what you need, no more. Maintain state on the client and it all hangs together nicely.

The big thing for me was to get my head around the fact that GWT isn't about building a web app. It's about building an app on the web. Very different thing.

GurffT

EDIT : Forgot to say, I do have a logic layer interacting with DAO objects server side - but they are pretty simple and just instantiated with new!