Spring Roo builds these forms based on the relationships that it can infer from the JPA mappings. Note that Spring Roo doesn’t strictly rely on the JPA associations, instead it relies on a generic model of the relationships that Roo maintains. This generic model could conceivably be used by other addons to plug in other types of models besides JPA.

There are tags for all the common types of data types. Roo does a great job mapping data types to the appropriate tags for forms or for display: booleans get checkboxes, small strings get an input field, large strings get text areas, and dates are rendered using a Dojo-based JavaScript date-picker. Roo employs its knowledge about your domain model’s relationships to correctly display a select form element for them (e.g., sets, and enums).

There is an empty label in the customer scaffolding form indicating that there’s no company specified (Figure 2-5). It’ll give you an icon that you can click, but this will fail, since there’s no scaffolding to support creating company entities. Since Roo hasn’t generated any scaffolding for our other entities, it can’t do much to ensure that the customer has a company, which is a required entity. This is also evident when you create a new customer—the application blows chunks because the foreign key for the company is null. We can create some scaffolding for all the entities in one go with the following command:

controller all --package ~.web

Figure 2-5. Crm crud forms

Once that’s done, redeploy and try the application again.

Figure 2-6. Create form with a relationship specified

Now, you’ll see that the blue icon takes you to a resource where you can create a new company. Create one (say, “VMware,” or “O’Reilly”), save it, and then return to the customers view. You’ll see that the empty label’s been replaced with a drop-down from which you can choose an entity.

Figure 2-7. STS agent reloading and publishing

Now you’ve got a fully working system to create and manage your entities. Each entity has a page (“/list”) that displays a grid of the available entities, and there are forms to view individual entities, create new ones and update or delete existing ones. Spring Roo’s resilient to changes, too. Open up the Customer entity and add a new Date field. You can use the command line, as before, or simply type in the following:

  @NotNull @DateTimeFormat(style = "S-") private Date birthday;

Save the entity and then watch the console; Spring Roo will update all of the existing scaffolding code. You’ll need to also update the database table with the new column. Issue this SQL on the console.

alter table customer
  add column birthday date not null;

Redeploy. A new date picker widget will be visible on the form. You can reorder the fields of the form in src/main/webapp/WEB-INF/views/customers/create.jspx.

Spring Roo will not override your changes, but it will still correctly add new ones when you change the entities. The secret Roo’s flexibility is the z attribute on the form field elements.

<field:datetime
     dateTimePattern="${customer_birthday_date_format}"
     field="birthday"
     id="c_com_crmco_crm_domain_Customer_birthday"
     required="true"
     z="3+6qO83ESYHcRPLijiOzV7iRvjU="
/>

It’s a hash that Roo calculates, based on the element name (name only, not namespace), attribute names present in element, attribute values present in the element. As long as this hash doesn’t change (which is true as long as you don’t do anything to change the identify, as described by this hash, of the element), then Roo can safely make changes to the element while you change everything see about the form, including position in the form and the surrounding HTML. If you make a change to the element manually, Spring Roo will notice this and update the “z” attribute to the value “user-managed.” Roo doesn’t manage all views in a project; typically it just manages the artifacts under the src/main/webapps/WEB-INF/views folder, and the menu.jspx file.

We’re a fair bit into this little book of ours, and we’ve learned a lot, but it’s worth noting just how much effort it would take to rebuild this entire application, soup to nuts:

persistence setup --database H2_IN_MEMORY --provider HIBERNATE
database reverse engineer --package ~.domain --schema PUBLIC
controller all --package ~.web

In addition to the above command line invocations, we also modified the Customer entity’s Java class directly, but you could just as easily have used the Roo command line to add those fields. All in all, we’ve achieved a lot for so very little.

Spring MVC’s got a lot of redeeming features that make it the most powerful web framework available to the Java developer today. Its annotation-driven programming model, the out-of-the-box abstractions to handle every manner of view (Tiles, PDFs, CSV and Excel spreadsheets, images, RESTful payloads like JSON and XML, etc.), its robust support for requirements typical of any serious Java application, all contribute to Spring MVC’s appeal.

Spring MVC applications, by default, don’t require an HTTP session. For many applications, an HTTP session is an extra weight that adds no value. The one place where HTTP sessions are valuable is in dealing with transient, client-specific state that has to be propagated across multiple requests. You might, for example, use an HTTP session to store the state associated with a shopping cart and checkout process. Typically such processes require the skilled management of object state over a series of several pages; they require foundational support for navigating backwards and forwards, much like a state machine. This sort of state is difficult to manage, however. There can only be one HTTP session associated with a client, no matter how many requests are made, which of course has the makings of a classic concurrency problem. Sessions are a shared resource. Spring WebFlow provides a framework specifically for managing problems like this.

You can install Spring WebFlow quickly by issuing the following command:

web flow

Spring WebFlow builds on top of Spring MVC, and shares common configuration and dependencies. Spring MVC and Spring Web Flow work well together, providing a powerful combo-punch for all the challenges you might face. The majority of your application will typically be developed in Spring MVC, with Spring WebFlow filling in the gaps where you need stateful, “conversational” interaction. Spring WebFlow, once configured, works by reading in descriptions of “flows,” described using Spring namespaces. These flows describe how pages in should be strung together in sequences.

Let’s look at the sample flow and folder that’s created when you install Spring Web Flow.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="http://www.springframework.org/schema/webflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/webflow http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
    <view-state id="view-state-1" view="sampleflow/view-state-1">
        <transition on="success" to="view-state-2"/>
        <transition on="cancel" to="end-state"/>
    </view-state>
    <view-state id="view-state-2" view="sampleflow/view-state-2">        <transition on="cancel" to="end-state"/>
    </view-state>

    <end-state id="end-state" view="sampleflow/end-state"/>
</flow>

The flow contains three meaningful stanzas: two view-states, and one end-state. These are only two of the many types of states that Spring WebFlow provides. Each state describes itself—in this case a view-state describes a view to dispatch to—as well as the transitions it might take. Spring WebFlow resolves views in the same way as Spring MVC, and here the values for view—sampleflow/view-state-2., and sampleflow/view-state-1 -map to Apache Tiles definitions, which in turn map to the JSPX files, just like the strings returned from controller methods in Spring MVC. SpringSource Tool Suite provides fantastic support for visualizing Spring Web Flows, just click on the “flow-graph” tab at the bottom of the editor panel when this flow is open. It produces a visualization of the graph. This visual view of the graph is editable; you can add new nodes to the graph by dragging elements from the pallette on the left onto the graph or alter the graph nodes by double clicking on the them and modifying their properties.

Figure 2-8. Webflow visualization

The specifics of Spring WebFlow are beyond the scope of this book, but getting started is easy—simply install the configuration from here, and then consult the comprehensive documentation at http://www.springsource.org/go-webflow2.

The first technology on our rich-client roundup is the Google Web Toolkit, or GWT. GWT is a cross compiler—it takes Java syntax code and compiles it into JavaScript. The libraries available to the developer using this cross compiler resemble a subset of the Java standard libraries, as well as several Java abstractions that are essentially mirrors of the common APIs that you would access running JavaScript in a browser, like the DOM.

To add new functionality to a GWT application, you can build complex abstractions using Java, or you can write JSNI—JavaScript Native Interface—adapter code and provide a Java binding for it. This has been used by many to, for example, expose the ExtJS JavaScript library as a Java API which can then be used in GWT code.

The GWT provides a convenient way for Java developers to build highly interactive, dynamic JavaScript applications with rich, client-side state. GWT applications may communicate with the server using a type of serialization that GWT recognizes.

Writing large, rich, cross-browser applications is easy with GWT. Java’s built in support for encapsulation and reuse lends itself to larger codebases. The JavaScript that GWT produces is very optimized—it’s as if you had the most intelligent JavaScript coder writing your code for you. The Java-to-JavaScript compiler can do things that you’d never do if you were writing JavaScript directly, including function inlining and obfuscation. The result is JavaScript code that’s blazing fast, if a bit ugly to look at.

To use GWT successfully, you need to set up the appropriate Eclipse plugins, configure GWT itself, and then connect your server side services to the client-side code.

To get started, simply run the following command:

web gwt setup

This single command takes care of everything and leaves you with a working GWT-based UI for your entities, in much the same fashion as the original Spring MVC application. Below is a screenshot. You can restart the Spring application inside of tcServer, and then start the GWT client side code itself. SpringSource Tool Suite already has all the Google plugins pre-configured to support development with GWT. Your Maven builds already been configured to correctly compile the GWT application code as well. To test your GWT code, open up the GWT entry point—an XML file at the root of your Roo base package (com.crmco.crm.ApplicationScaffold.gwt.xml—and right click on it in the Source code editor window. Choose Run As > Web Application. This will launch a browser with your code. During development, GWT runs in “hosted mode.” Hosted mode is an environment that lets GWT connect your code to the IDE (and the debugger). To support Hosted Mode, you need a plugin in your browser that can communicate back to your IDE. You will be prompted to install this plugin if you don’t already have it when you first run this application.

The application should look something like this:

Figure 2-9. CRM-GWT editing

SpringSource Tool Suite includes all the sophisticated tooling to support development with GWT. Indeed, the Google plugin that comes prebundled with SpringSource Tool Suite also supports other Google technologies, like Google App Engine. Incidentally, Spring has the distinct position of being the only enterprise Java framework that works portably on all the major cloud environments, including Google App Engine, Amazon Elastic Beanstalk, and of course, CloudFoundry. The Google plugin includes a visual designer for GWT, which you can use by clicking on a GWT XML artifact and then clicking on the “Design” tab at the bottom.

Figure 2-10. GWT visual designer

GWT is an example of SOFEA -- service oriented front end applications. In an SOFEA application, clients make requests against server side resources to activate business logic and marshal server side state back and forth using dumb objects (which smells suspiciously like a DTO). This has the benefit that server side state is kept to minimum, assuming of course that the services invoked are stateless as well. However, the resulting code is filled with much more boilerplate code and more prone to security concerns.

Vaadin is different. Vaadin is built on top of GWT, and comes with a large array of components, but these components are different than typical GWT widgets. Vaadin widgets, as run on the client side, are simply stateless “proxy” widgets that delegate all their business logic (and state management) to a server side peer. Thus, Vaadin applications make a lot more calls to the server, and the server keeps all the UI state, not the client as with GWT. Because all the business logic runs on the server side, and because all the UI state exists on the server side, the client needs only to be responsive and to convey state changes to the server. Keeping the important business logic on the server simplifies things a lot—it means you can avoid tedious code to serialize Java objects back and forth as JavaScript objects, and any concerns about security are minimized because all the business logic runs on the server side, away from prying eyes.

A cursory examination of the code in our previous GWT example will reveal a lot of boilerplate code. Roo certainly got the ball rolling for us, but if the code it generated is any indication, then there’s a lot of code to be written for a typical GWT application. Vaadin solves this problem by providing a rich set of components and framework code that greatly reduces the developer footprint.

To use Vaadin with Spring Roo, you first have to install it. It is not shipped out of the box with Spring Roo, but instead is part of the huge, ever expanding ecology of Spring Roo addons.

pgp trust --keyId 0xBF0451C0
download accept terms of use
addon install bundle --bundleSymbolicName com.vaadin.spring.roo.addon

Once this is done, you can now start using the Spring Roo Vaadin addon. Issue the following command to have the Roo addon generate scaffolding for our entities, in the same way that we used the MVC and GWT addons to generate scaffolding.

vaadin setup --applicationPackage ~.web --baseName crm --themeName crm --useJpaContainer false

This will install Vaadin, add the required Java dependencies, update web.xml, etc. It installs some helper and utility code in the com.crmco.crm.web package. Inspect that package and you’ll see a handful of classes, a far cry from the reams of code implanted by the GWT addon. Let’s see what Vaadin can do for us in terms of scaffolding. Run the following command to generate CRUD forms.

vaadin generate all --package ~.web.ui --visuallyComposable true

Figure 2-11. Vaadin crm

The generated Vaadin application is pretty striking, and doesn’t take a lot of code! Vaadin also has a visual designer that you can use. You need to add the Vaadin Eclipse plugin to SpringSource Tool Suite. In SpringSource Tool Suite, go to Help > Install New Software, and in the “Work With:” field, enter the URL of the Vaadin Eclipse update site, http://vaadin.com/eclipse. Select the “Vaadin” tree, and install everything. Follow the prompts. Once everything’s configured, you can open any Vaadin form in the Vaadin visual designer. Right click on the com.crmco.crm.web.ui.CartOrderForm, choose Open With > Vaadin Editor. If you find yourself looking at source code, then look at the bottom of the editor pane and click on the Design tab. You should be shown a visual approximation of the design, just as with the GWT designer. You can select elements and modify them in the visual tool, as well.

Figure 2-12. Vaadin visual designer

While we haven’t covered all the supported technologies, there are numerous other addons that support Flex, Wicket, and many other technologies.

Many of these technologies—like Flex, GWT, and Vaadin—are geared specifically to form-intensive, rich-client-type applications, and not to being a general purpose web framework like Spring MVC. We think you’ll find that most applications are best served by introducing Spring MVC (and perhaps Spring WebFlow) as the base, and then—as islands of richer, page-centric functionality are required—by introducing something like Vaadin.