In the GWT tutorial we used the sandbox Derby database that comes with ME4S to build out a GWT application that manages customers and payments using the Customer and Payment tables as inputs to the process. The resulting application looks something like this:
This application gives you the basic CRUD capabilities for managing your Customers and Payments and has a few nice capabilities built-in, including sortable, paginating lists, “Pickers” for adding and removing elements from relationships, multi-tabbed editing, etc. This UI is really a composition of several nice, reusable components that can be re-purposed into other designs. Because we are using a Command Pattern, Event Bus, and MVP based architecture, it is easy to wire these components together into different application patterns down the road.
Understanding the Architecture
After you have watched the Google I/O presentation on architecting GWT Applications, you will find the following illustration helpful in building a mental picture of the architecture that is being employed. The key architectural benefits are the clean separation between the Model, which is dumb, and the View, which is also dumb, and the Presenter, which isolates the logical (and testable) code in your application. The Actions and Events being used on the EventBus allow the code in your application to be extremely loosely coupled. The RPC Service Layer and Server Side GWT Remote Service act as an asynchronous information service. In this case, the GWT Service is backed by the generated Spring / JPA backend.
Reusable Software Components
The following diagram illustrates the reusable software components that have been generated into your project as a result of the GWT scaffolding execution. The Scaffolding Wizard allows the developer to pick the layers that they wish to generate and those they wish to exclude. In this case, we generated a standard Spring layered server side architecture with a Service, DAO and Domain layer, as well as a Web layer that is build upon GWT. The GWT Components generated offer additional detail regarding the code that is used to implement the Architecture as it was illustrated above.
The ME4S Scaffolding Wizard gives you options for where you would like to put your code, how it is packaged, etc. Let’s take a look at the default project layout for the application described above.
If we take the defaults, all of the generated code and configuration will go into a folder called “generated”. You can still build all of your own code in the existing src folder and leverage the code in the generated src folder. The generated code has absolutely no tie back to the tooling or generation technology. You can take this code and do what you like with it at this point. If you want to be able to run the scaffolding repetitively, you should avoid making changes in the generated .java files, although there are options to deal with re-generation which we will detail in a separate blog.
The “server side” components are put in the com.show. – (dao, domain, and service) packages. The packages that start with gwt.- are the gwt software components. ME4S generates a separate GWT module for each Domain object so that you can mix and match them later, plus a common module with utility classes, and an entry point module that rolls them all up into an example GWT application.