Posts Tagged ‘dwr’

« Older Entries

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.

springdslabstraction

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.

springdslinstantiation

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).

springdslservices

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.

springdslproject

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.

springdslcomponent

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.

Completed Fantasy Football CRUD Application

In this blog, I will show how to very easily create the CRUD Spring DWR EXT JS application with an Ext.grid.EditorGridPanel above using Skyway. This implementation is similar to Skyway’s first President sample project, except that we are now adding DWR into the mix by using Skyway Builder 6.3 Web Service Edition.

This blog is divided into 2 parts:

Prerequisites

Step 1: Create the Java Spring CRUD App (in seconds)

This step will go into the basics of Skyway CRUD Scaffolding. If you need more detail on how to do CRUD Scaffolding in Skyway, which creates an ENTIRE Spring CRUD app in seconds, please take a look at the CRUD App Scaffolding Jump Start document or video.

  1. Create a new Skyway project. In this example, I’ll use a project called FantasyFootball.
  2. Create a new Domain Object, named Team under a new Model Package named com.ff.domain.
  3. Add the following fields: tId (primary key – text), name (text), owner (text), wins(integer), losses(integer). Be sure to check tId as the primary key. (see screenshot)
  4. Save the DO, right-click on the visual DO artifact in the Project Explorer and choose Scaffolding > Generate CRUD

Step 2: Tweak the CRUD

In almost all cases you’ll want to tweak the CRUD app or build more on to it.  Follow these steps to tweak the FantasyFootball project.

  1. Delete MVC: You won’t be needing Spring MVC for this since we are using DWR.  So, feel free to Delete the entire Spring DSL > com.ff.web Model Package.
  2. Update Service Inputs: In the Skyway Project > Spring DSL > com.ff.service, check the Collection checkbox for both the DeleteTeam and SaveTeam service.  You may also want to change the plurality of the input variable.
  3. Enable Spring DWR: Double-click the com.ff.service > TeamService artifact in the Spring DSL.  Go to the DWR tab, and click the Synchronize button.  Highlight TeamService [DWR Service] in the Direct Web Remoting Services text area, and check the Publish checkbox on the right hand side.  (see screenshot)
  4. Update DWR Spring Config: Take a look at FantasyFootball-Web (Project) > WebContent > WEB-INF > config > FantasyFootball-generated-dwr-config.xml, and change the dwr:configuration tag to contain the following correct Team bean convert tag: 
    <dwr:convert type="bean" class="com.ff.domain.Team" />

    Feel free to run the application at this point to test the DWR calls.  You can use the Spring default test page at http://localhost:8080/FantasyFootball-Web/dwr/

  5. Remove Sidebar: Skyway’s CRUD Scaffold feature adds sitemesh and a menu bar for Spring MVC links.  This is not applicable in our EXT JS app, so, you will want to delete the sidebar div in FantasyFootball-Web (Project) > WebContent > WEB-INF > sitemesh-decorators > main.jsp.  It’s the first div inside of the contentWrapper div.
  6. Comment out style.css: Since we will be using the EXT JS css, you will need to comment out everything (or delete) after the #loginContent class definition in FantasyFootball-Web (Project) > WebContent > css > style.css

Step 3: Add the EXT JS

Covered in Part 2

Page 1 | 2 | >

In Part 2, I detail the last step in this 2 part blog series, which is to add the EXT JS code.

Step 3: Add the EXT JS & Run

  1. Add EXT files: From the prerequisites section, add the following files to your project:
    • DwrProxy.js into FantasyFootball-Web (Project) > WebContent > js
    • ext-all.js into FantasyFootball-Web (Project) > WebContent > js
    • ext-base.js into FantasyFootball-Web (Project) > WebContent > js
    • ext-all.css into FantasyFootball-Web (Project) > WebContent > css
    • EXT JS default images folder (EXT distribution > resources > images) into FantasyFootball-Web (Project) > WebContent > images
  2. Create the EXT Grid: Create a new file named teamcrud.js and place it in the WebContent > js folder.  This file will create the Ext.grid.EditorGridPanel and add all the necessary script to support the CRUD functions.  To see the final version, either download the completed app in the Appendix section or go to this link: teamcrud.js. Here are some items to consider if building the Grid yourself or if you are trying to figure it out for the first time:
    • The core of teamcrud.js is the Ext.data.Store, which uses DwrProxy, JsonReader and JsonWriter.
    • Notice the clean DWR CRUD implementation provided by DwrProxy.  All you need to do is specify the Javascript DWR calls, which can be easily found in the source of the DWR test page. Skyway CRUD uses the nomenclature found in the code below.
    • Also notice the update handler, which implements an override to pass the TeamService.saveTeam DWR call. The CRUD scaffold Service is expecting the updated Teams only. More enlightening details on this change can be found at this EXT JS post.
    • Deletes will only work if idProperty is defined.  If not explicitly defined in the JsonReader, it will use a field name of “id” if exists.  If you use something else, you will need to define idProperty.
    var reader = new Ext.data.JsonReader({
    idProperty: 'tId',
    fields : [
        {name: 'tId'},
        {name: 'name', type: 'string'},
        {name: 'owner', type: 'string'},
        {name: 'wins', type: 'int'},
        {name: 'losses', type: 'int'}
]});

var writer = new Ext.data.JsonWriter({
    writeAllFields: true,
    listful : true
});

var TeamsDataStore = new Ext.data.Store({
id: 'TeamsDataStore',
proxy: new Ext.ux.data.DwrProxy({
apiActionToHandlerMap : {
    read : {
        dwrFunction : TeamService.loadTeams
    },
    create : {
        dwrFunction : TeamService.saveTeam
    },
    update : {
        dwrFunction : TeamService.saveTeam,
        getDwrArgsFunction: function(request, recordDataArray, oldRecordDataArray)
            {
            return [recordDataArray];
            }
    },
    destroy : {
        dwrFunction : TeamService.deleteTeam
     }
 }
 }),
 reader: reader,
 writer: writer,
 autoSave: true,
 sortInfo:{field: 'wins', direction: 'DESC'}
 });
  3. Finally, add a new file named index.html to FantasyFootball-Web (Project) > WebContent.  All you need to add are the javascript links below between the head tags: 
    <link rel="stylesheet" type="text/css" href="css/ext-all.css" />

<script type="text/javascript" src="js/ext-base-debug.js"></script>
<script type="text/javascript" src="js/ext-all-debug.js"></script> 

<script type="text/javascript" src="js/dwrproxy.js"></script>

<script type='text/javascript' src='dwr/interface/TeamService.js'></script>
<script type='text/javascript' src='dwr/engine.js'></script>
<script type='text/javascript' src='dwr/util.js'></script>

<script type="text/javascript" src="js/teamcrud.js"></script
  4. Run the App: The application is now ready to run.  Enjoy your Skyway Generated Spring CRUD DWR EXT JS with EditorGridPanel Application!

Appendix & References

Page < | 1 | 2

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 implemented the back-end of the GWT application using Spring and Direct Web Remoting (DWR).  In part three we started to create the  GWT front-end.  In this post I’ll wrap up the implementation of the front-end, including the integration between GWT and DWR using GWT JavaScript Native Interface (JSNI).

Read the rest of this entry »

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 implemented the back-end of the GWT application using Spring and Direct Web Remoting (DWR).  Now we will build the GWT front-end.

Before we get started lets me make it clear that I will  describe the steps for creating the GWT front-end, but I won’t be explaining GWT development concepts in much detail.  I’m assuming that you already understand GWT.  You definitely don’t want me, a self-professed GWT novice, teaching you GWT.  If you aren’t familiar with GWT, then I recommend you start with the GWT tutorial.  As I stated in earlier blog posts, the purpose of this series of blog posts is to share with you one approach to integrating a GWT front-end with Spring-based back-end services.  This is a topic that I think I have a pretty good grasp of, but I certainly welcome feedback.  I am describing the steps for creating the GWT front-end only for the sake of completeness of the integration example.

Read the rest of this entry »

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).

Read the rest of this entry »

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…

Over the last month (when time permitted) I have been experimenting with Google Web Toolkit (GWT) for RIA development.  I have benefited a lot from the efforts of other developers that have blogged regarding GWT development, and it’s definitely expedited the GWT learning curve for me.  In the spirit of community I figured I’d share my experiments with the Spring, Skyway Builder, and GWT development community.  Hopefully others will find the information here helpful.

My specific goal was to use Skyway Builder 6.3 to generate the Spring back-end of a GWT application and use basic GWT development techniques for the front-end.  There are many ways for a GWT application to integrate with server-side logic, and the specific approach that I took was to use the DWR functionality in Skyway Builder EE.  In the future (if someone else hasn’t beat me to it) I’ll will explore and share other ways to leverage Skyway Builder for integrating GWT and Spring development.

Rather than just tell you that my experiment was successful, I wanted to describe the steps that I took in detail.  As a result, this series of blog posts will resemble a Skyway Recipe, and I hope to provide sufficient details so that you can recreate this project on your own.  This series will consist of five parts:

Read the rest of this entry »

« Older Entries