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…

This blog post is the last post of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In part three I describe the actual implementation of the Spring DSL extension, and in this post I will describe how to download, install, and use the extension.

The GWT extension for Skyway Builder is implemented as an Eclipse plugin.  As such it needs to be installed as an Eclipse plugin.  In the future I may create an update site, but for now you can download the plugin (com.skyway.experimental.integration.gwt_1.0.0.jar) and copy it into the plugin folder for Eclipse.  Just as a reminder this plugin is dependent on having Eclipse 3.4.2 plus Skyway Builder 6.3 (Standard Edition).  If you don’t have Skyway Builder Standard Edition, you can get a copy from here.

When you restart Eclipe the GWT extension for Skyway Builder is ready to go.  For any Spring DSL Services or Components that you have defined in any projects, Skyway Builder will start generating slightly updated or new artifacts (see post two for details).

Here’s an important consideration.  This experimental plugin was designed to toggle the generation of GWT artifacts (using the Code Generation tab), and by default the generation is turned on.  This means that it will affect all Services.  If you have any existing projects that you don’t want to be affected by the GWT extension, you will need to disable the generation of the GWT artifacts by unchecking the GWT entries from the Code Generation tab of the Spring DSL.

A better solution is to add an attribute to the definition of the service that will allow me to specify the Service should be GWT enabled.  That’s exactly the approach taken by the DWR and JAX-WS features in Skyway Builder.  When you check “Publish DWR” or “Publish Web Service” checkboxes, the service will be generated accordingly.  Perhaps I’ll tackle that in a future version of the plugin.

Here’s an example of using the new plugins.  I followed the instructions from a previous blog post (GWT and Spring: Setup of development environment and Create GWT project).  The only difference is that this time I’m using GWT 2.0 instead of GWT 1.7, and I also added the spring4gwt library to my project.  Before I start doing any code generation with Skyway Builder, I want to quickly configure the Spring DSL to generate the correctly generate the new artifacts.

The Code Generation tab of the Spring DSL is used to define the code generation defaults for the project.  You will notice there are some new code generation entries that are contributed by the new plugin.  The first step is to disable “Service Interface” generation.  I recommend sorting the table by Categories in order to see all the Service entries grouped together.  The next step is to configure the “Service Interface“, “GWT Service Interface“, and “GWT Service Async” entries with a different package.  By default they are set to ${model.package}, which means that the artifact will be generated to a java package corresponding to the model package of the Service.  However for GWT we want the interfaces generated into their own package, so we are appending “.interfaces” to the end of the package.  I won’t go into all the details why this needs to be done for GWT, but suffice it to say that it’s a GWT best practice to isolate client-side and server-side Java code so that the GWT compiler will only compiling relevant Java code (source path) to javascript.

To see the GWT extension for Skyway Builder in operation, you can create Spring DSL services by hand or you can quickly scaffold a Spring MVC application.  For this blog post I scaffolded from a domain object.  See step 9 from GWT and Spring (Part 2) – Scaffold Spring back-end for GWT Application for a quick explanation on how to scaffold a Spring MVC application with Skyway Builder.

In my example you can see that the ContactService (in Spring DSL) generated the implementation class, service interface, and asynchronous callback interface (for GWT).  As you add new operations to the service, all the artifacts are regenerated to reflect the changes.

As far as events are concerned, you can just create a model package whose corresponding java package will be listed as a source path in GWT application, which will result in it being compiled into javascript.

This concludes my series.  My hope is that I provided an easy to understand introduction on how to extend Skyway Builder and an extension that may be usefull to GWT developers using Spring as their backend.  If you have any questions or would like me to elaborate on something, please drop me a comment here.

What’s next with this plugin? I’m glad you asked.  I would like to expand the support for GWT development in Skyway Builder.  I had started experimenting with some GWT UI scaffolding, and I’m making some good progress.  However given the new UI Binder feature in GWT 2.0, I will need to re-examine this.  If you have any ideas for enhanced GWT suppport, please let me know.

Happy New Year!!!

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…

This blog post is the continuation of a series of blog posts related to extending Skyway Builder to enable some code generation support for GWT, including the automated  access of Spring @Services for GWT RPC.  In part one I gave an overview of the Skyway Builder extension in relation to GWT, and in part two I gave an overview of how Skyway Builder will be extended to support GWT development.  In this post I will describe the implementation of the Spring DSL extension in more detail.

If you don’t so much care how the GWT extension for Skyway Builder is implemented and just want to start using the extension, then you will probably just want to skip to part 4 where I will describe how to download, install, and use the extension.

Since the general steps for extending in Skyway Builder are already described on Modifying Artifact Generation in the Skyway Wiki, in the post I’m going to focus specifically on how these steps were applied to create the GWT extension.

Following the setup instructions, first of all I created a Jet Transformation project called com.skyway.experimental.integration.gwt.  I accepted all the defaults in the wizard.  Next I added required dependencies.

I’m going to use JET to implement my code generation templates.  JET templates resemble JSP in many ways, making it very easy to follow the implementation of the templates.  JET supports the concept of tags and tag libraries (just like JSP).  The JET tag library is very rich in generation functionality, but you can also use custom or 3rd party tag libraries (just like JSP).  Skyway Builder contributes a set of JET tag libraries for simplifying many of the recurring generation requirements of Spring applications.  A full reference of the Skyway JET tag library can be found here.  In regards to the GWT extension, the  Skyway JET tag library need to be added as extension.

The next step is to add the artifact definitions for the new artifacts that are going to be generated and register the template overrides for the pre-existing artifact definitions.

This diagram shows the extension entries required to accomplish the functions described in post 2, which includes:

• adding a new Service artifact definition for the GWT callback interface
• adding a new Service artifact definition for the service interface (the decision to create new artifact definition instead of overriding existing template will be described in part 4)
• overriding the JET template for generating the web deployment descriptor (web.xml)
• overriding the JET template for generating the Spring context file for the service layer
• adding a new Component artifact definition for generated GWT events

I won’t review each JET template, but the the project contains five new templates.

Here’s a summary of each template:

• generated-service-context.jet – This template is a copy of the base template and includes additional logic to direct Spring to do a component scan of all annotated Spring components.  By default the component scan is done from the web context file, but GWT front-ends talk will directly to the service layer (and bypass the web layer).  Therefore the component scan needs to be done from service layer, otherwise the dependencies of the Service layer won’t be resolved by Spring.
• gwtEvent.jet – This new template generates a GWT event Java class from a Spring DSL component.  The component name is used as the event name, and the component variables are use for generating the event payload.
• gwtServiceAsync.jet - This template is a new template that generates the GWT callback interface, which is a requirement for using GWT RPC.
• gwtServiceInterface.jet - This template is a copy of the base template and includes additional logic to emit an @RemoteServiceRelativePath annotation for each service operation.
• web.xml.jet – This template is a copy of the base template and includes additional logic to register the spring4gwt servlet and servlet mappings.

That’s it for the plugin.  The next step is to export the plugin (Export –> Deployable plug-ins and fragments).  The resulting plugin (jar file) can be installed into an Eclipse instance with Skyway Builder 6.3.  I’ll cover that in more detail in the next post (part four).

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 the previous post I introduced a new GWT extension for Skyway Builder that automatically makes Spring @Services accessible as GWT RPC services and accelerates the development of GWT events that can be used with a GWT event bus.  This blog post will provide a high-level description of the implementation of the extension, and in the next blog post I will dive into the implementation details .

I’m not going to spend a lot of time explaining how spring4gwt works.  Please refer to the project site for detailed description of spring4gwt.  There are essentially five steps for making Spring @Services accessible as GWT RPC Services using spring4gwt.

Implementation requirements for producing GWT RPC services from Spring Services:

1. Copy Spring4GWT library into project
2. Modify web application context file (web.xml) – add spring4gwt servlet and servlet mapping
3. Create a a GWT callback interface for the Spring @Service – each service operation should be reflected in callback interface
4. Modify the service interface – add import statements for GWT remote service; add @RemoteServiceRelativePath annotation; extend Remote Service
5. Modify service context file (Spring) - since GWT clients replace JSP and controllers, the component scan that is typically located in the web context file needs to be moved to the service context file, otherwise the Spring framework won’t be able to find other components that the service might be reliant upon.

Except for the new GWT callback interface, all the relevant artifacts are already generated by the Spring DSL.  The GWT extension will just need to customize the generation of these artifacts to support GWT RPC using spring4gwt.  The callback interface, on the other hand, is a new artifact, and the Spring DSL will need to be extended to generate it.

Here’s what you need to know about the Spring DSL.  The Spring DSL defines 10 abstractions, which include Project, Controller, Component, Service, Domain Object, Data Access Object, Operation, Named Query, Exception and Action.  Each Spring DSL abstraction will generate primary and secondary artifacts, and the generated artifacts are typically Java code or XML configuration files, although you really can generate anything that can be emitted with JET.

During the course of application development using the Spring DSL a developer will define instances of  Spring DSL artifacts, and Skyway Builder will generate the primary and secondary artifacts according to the configuration of the Spring DSL artifacts.

For the GWT RPC functions the two relevent Spring DSL abstractions are: Project and Service.  According to the Spring DSL there are 6 artifact definitions for a Service, and the following diagram shows the most relevant ones -plus- the new artifact definition (GWT Interface).

For the Service interface the GWT extension will override the default code generation template that’s provided by Skyway Builder, and the new template will emit code required in the service interface (see requirement #3).  For the GWT callback interface (requirement #4) the GWT extension will extend the definition of a Service by adding a new artifact definition and contributing a new code generation template.

Now that requirements 3 and 4 are out of the way, let’s proceed to requirements 2 and 5.  These requirements will be handled in a very similar manner.  The web.xml and Spring context files are generated by the Spring DSL Project abstraction.  There are a lot of artifacts generated from a Project, so the following diagram only shows the most relevant ones.

The GWT extension will override the code generation templates for web.xml and service context file.  The new templates will add the additional configurations needed to support GWT RPC.

In the grand scheme of things this exercise was pretty trivial because all the required steps are handled by the GWT extension by just overriding an existing template or contributing a new artifact definition to an existing Spring DSL element.  It’s worth noting that this is just the tip of iceberg when it comes to extending the Spring DSL.  If needed you could extend Spring DSL element to capture more metadata, which presumably would be used to drive the code generation.  You could also create entirely new Spring DSL elements with their own meta-data and code generation templates.

The implementation overview of the GWT RPC function is complete, and now we will proceed to the GWT Events function.  For this function I needed to decide whether or not I should create an entirely new Spring DSL element for Events or whether I could use a pre-existing Spring element.  For the sake of simplicity I decided to use the existing Spring DSL Component element because it already captures all the metadata that I need for generating Events.  Components have a name, which I’ll use as the event name, and components have variables, which I’ll use for defining the event payload.  Here’s the definition of a Component -plus- the new GWT event.

The process for adding support for generating GWT events from a Component is nearly identical to the process of generating the callback interface from a Service.  The GWT extension defines a new artifact definition for Spring DSL Components, and a new code generation template will be used to produce GWT events.

As you can see it was relatively simple to customize the Spring DSL, and the basic recipe described in this post can be applied to countless development scenarios.

If you are familiar with Skyway Template Projects, you may be wondering how this process is different than Skyway Template Projects.  Both let you customize the code generation templates, so why was an Spring DSL extension used instead of a Skyway Template Project.  While Spring DSL extensions and Skyway Template Projects share some functionality, you can do a lot more with the Spring DSL extensions. I already pointed out that this recipe is just the tip of the iceberg when it comes to extending the Spring DSL.  While Template Projects let you customize the templates, they don’t let you add new artifact definitions (which was one of the requirements of the GWT integration), extend the Spring DSL with additional metadata, or define entirely new Spring DSL abstractions.  If you are only interested in overriding pre-existing code generation templates for pre-existing Spring DSL abstrations, then the Skyway Template Project is your best bet.  However Skyway Template Projects weren’t adequate for the GWT-RPC or GWT events requirements.

In the next post I will describe the implementation of the extension in more detail.

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…

A few months ago I did a series of posts related to GWT, and in the posts I covered the creation of a Google Web Toolkit (GWT) application that uses Javascript/JSON services provide by the new Direct Web Remoting (DWR) generation feature [Video] of Skyway Builder 6.3.  The feedback to the DWR feature has been excellent.  Since Skyway Builder takes care of generating all the DWR configuration, AJAX developers are able to focus their efforts on development of the front-end.  While the DWR generation feature was the star of the series, writing the blog posts really sparked my interest in GWT.  As I investigated GWT further and experimented with other GWT development projects, I decided that I needed to revisit the integration between the GWT front-end and Spring-based back-end application.  With the help of others I came up with an implementation that I think is better than the DWR approach.  I also found that the implementation could be expedited using code generation, and I built a GWT extension to Skyway Builder that handles most of the work.  In the next few blog posts I will describe the GWT-Spring integration strategy and the implementation of the experimental Skyway Builder extension for GWT development.  At the end of the series I will provide a download link for the GWT extension for Skyway Builder.

Before I dive into the new GWT-Spring integration strategy let me point out that the Javascript/JSON approach described in the original posts is still perfectly valid.  I have talked to other GWT developers, and there is nothing wrong with the original approach.  As a matter fact using Javascript/JSON is highly recommended for scenarios where the back-end is not Java based.  However if you happened to be using Java back-end (like I do), GWT provides an RPC mechanism using Java servlets.  The primary benefit of GWT RPC is that the developer doesn’t need to worry about serialization/deserialization of data, and the GWT compiler has the opportunity to optimize the client-side RPC logic.

Let me take a moment to describe my ideal development scenario in regards to GWT and my Spring back-end.  Web applications are typically organized into layers, and the most common layers are web, service, domain and DAO.  If I’m developing an HTML application (traditional or light AJAX), then the web layer consists of my JSP pages and controllers, which call the application logic contained in the service layer.  I consider a GWT client to be an alternative to JSP pages and controllers in the web layer, and the GWT client should be able to leverage the same application logic in the service layer.  In the GWT/DWR blog post series the Spring DSL Services were DWR-enabled, making the respective Spring @Services accessible to clients via javascript and JSON.  I expect the GWT RPC mechanism to be structured in the same manner, and ideally the Spring @Services will be accessible as GWT RPC services.

While GWT RPC provides an RPC mechanism, there was still some work to be done to get it to talk to my Spring Services.  Not wanting to reinvent the wheel, I did some investigating on how others solved this problem, and I found the Spring4GWT project.  What Spring4GWT basically does is to make it easy to expose Spring @Services as GWT RPC services.  The @Services generated by the Spring DSL are already in excellent shape to use with Spring4GWT.  There were only two additional requirements to use Spring4GWT.  First of all I needed to register the Spring4GWT servlet for handling GWT RPC requests, and I also needed to modify the service interface to support GWT callbacks (AsyncCallback).  While these requirements are easy enough to do manually, the GWT extension for Skyway Builder will handle this (plus a few other things) automatically for you.  Automating this allows me to just focus on the services themselves, without being bothered by keeping the interfaces and Junit tests in sync.

What’s really cool about this is that when I combine the capabilities of the GWT extension with the Spring scaffolding capabilities of Skyway Builder, I can go from a database table (or set of tables) or domain object(s) to a fully implemented Service layer with GWT RPC support in less than a minute.  Furthermore if I enable the DWR and JAX-WS checkboxes, I have a scaffolded service layer that’s accessible using Java, Spring DI, GWT RPC, DWR and JAX-WS in less than 2 minutes.  However I digress.

My perspective may be uncommon, but I always look at development from the perspective of code generation.  While generating GWT RPC ready back-end Spring applications definitely accelerates GWT development, I found many other opportunities for GWT code generation that can further accelerate GWT development.  In this series of blog posts I will describe and share one of the additional GWT code generation functions, and this function is applicable to all GWT development….not just GWT development that’s using Spring back-ends.

While exploring GWT development I have been studying up a bit on  best practices on GWT development.  There’s an excellent presentation (Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App) by Ray Ryan from Google that was very educational.  It’s a very worthwhile presentation, and I encourage all GWT developers to watch it at least once.  One of the recommendations of the presentation was to use an event bus.  Event buses are very interesting.  While it take a little bit more time to get it set up intially, I find event buses save a lot of time in the long run…and makes development much easier by decoupling GWT artifacts.  I adopted an EventBus implementation call GWT-EB.  While it worked very well, I found that creating events was a bit tedious.  Except for the event payload (the data that travels with the event), the implementation of events is mostly boilerplate code.  This seemed to me like a great opportunity for code generation.  So I added a code generation function to the GWT extension for Skyway Builder to generate the GWT Events.  With the GWT extension, creating events is now just a matter of giving it a name and specifying the payload (if applicable).  The GWT extension for Skyway Builder will generate the GWT events.

In the next few blog posts I will describe the development, installation and use of the GWT extension for Skyway Builder.  In addition to providing some GWT code generation that can be immediately used for GWT application development, it will serve as a good case study for extending the code generation features of Skyway Builder.

Stay tuned.

Update: Part 2 can be found here.