Update 7/9/2010 – MyEclipse for Spring 8.6 now generates full ready-to-run GWT applications based on MVP and UI Binder in minutes. Just point the scaffolding wizard at your database tables, Java beans, or JPA Entities. You can learn more about it from the Generating Enterprise Class GWT applications for Spring post that I wrote on Genuitec blog. Or, you can keep reading my original post…

In part one we installed the Skyway Builder plugins and the Google Plugins for Eclipse, and we created the GWT project (dynamic web project) and the Spring DSL project.  In part two we are going to implement the back-end of the GWT application using Spring and Direct Web Remoting (DWR).

The GWT application that we’re going to build will essentially consist of CRUD functionality.  While we could build the Spring back-end from scratch using the Spring DSL, we’re going accelerate the development by scaffolding the back-end.  By defining just the domain model, Skyway Builder will generate all the back-end logic, including the Spring @Service components and the JPA data access objects (DAOs) required for CRUD functionality.  For the purpose of this blog post, the scaffolded service and data layers are going to be sufficient.  Of course there’s nothing preventing you from further enhancing the service and data layers using the Spring DSL.

The Spring MVC scaffolding engine in Skyway Builder will create the web, service, and data layer components for managing the domain objects.  The GWT application doesn’t require the web layer of the scaffolded application.  As mentioned earlier, our GWT application only requires the scaffolded service and data layers.  However we will use the fully scaffolded Spring MVC application for entering data prior to building the GWT front-end and testing the DWR services.

Step 9: Scaffold from Domain Model

The steps for scaffolding are very easy.  We’re going to define our data model using the Spring DSL.  We could have instead derived the data model from an existing database (See Skyway Recipe: Generating Domain Model from an existing database), but that is beyond the scope of this blog post.

Here are the scaffolding steps at a high level:

• Create a Model Package ( TodoModels:Spring DSL –> right-click –> New –> Model Package): org.todo.domain
• Create Domain Object: (org.todo.domain –> right-click –> New –> Domain Object): Task
• Add the following fields to the domain object

• Scaffold Domain Object (Task –> right-click –> Scaffolding –> Generate CRUD)
• Configure your DAO with DB connection (Double-click TaskDAO –> Switch to Database Connection tab)
• Regenerate and rebuild project (Project –> Clean)

Deploy the TodoGWT (Dynamic Web Project) to application server, and run the application.  Assuming you’re using Tomcat, the url is http://localhost:8080/TodoGWT/pages/task/index.jsp.  You may want to add a few records to verify that the generated Spring MVC application is running correctly.

Step 10: DWR Enable the Spring Services

Now that we have a fully running services and data layer, we need to expose the Spring @Service components in a manner that can be consumed by the GWT front-end.  As I mentioned in part one there are various available integration techniques, and I chose to provide a javascript/JSON interface to the Spring services using DWR.  The GWT front-end will interact with the services using the javascript/JSON interface.

Here are the steps to DWR-enable the scaffolded Spring services:

• Open the DWR editor for the Spring Service (TodoModels –> Spring DSL –> org.todo.services –> double-click TaskService –> switch to DWR tab)
• Synchronize the DWR Services, and enable the TaskService for DWR by checking the Publish checkbox.

• Regenerate and rebuild project (Project –> Clean)

If you are interested in a more detailed explanation of using the DWR functionality in Skyway Builder, check out Skyway Recipe: Publishing a AJAX service using DWR.

Step 11: Test Javascript/JSON interface

When you redeploy the application, you can verify that the service is DWR enabled by accessing the DWR testing page (http://localhost:8080/TodoGWT/dwr/index.html)

You will notice that the testing page will be displayed within the layout of the scaffolded Spring MVC application.  That’s because the scaffolded Spring MVC application is using sitemesh.  To prevent sitemesh from affecting the look-and-feel of DWR test page,  you can update the sitemesh decorators.xml file to exclude dwr urls.

<excludes>
<pattern>/j_spring_security_logout</pattern>
<pattern>/pages/logout-redirect.jsp</pattern>
<pattern>/dwr/*</pattern>
</excludes>

The backend for our GWT application is done.  In the remaining posts I will cover the implementation of the GWT front-end, and I’ll describe how the GWT front-end is integrated with the DWR-enabled back-end logic.

This series consists of five parts:

• Part 1 – Setup of development environment; Setup of the GWT project
• Part 2 – Scaffold Spring back-end for GWT application
• Part 3 – Create GWT Front-end Skeleton
• Part 4 – GWT and Spring Integration
• Part 5 – Deploy and Test GWT application on Tomcat