Gaijin Studio for Spring MVC 0.9.2 Released

The 0.9.2 release of Gaijin Studio for Eclipse is now available. It adds a number of features that were requested by the community and continues to refine the process of generating Spring MVC code from process flow metadata. The project is open source (LGPL) and may be downloaded at gaijin-studio.org.

Code:

---

Gaijin Studio Features

Gaijin Studio extends the Eclipse IDE to facilitate building applications based on
the Spring MVC framework. Gaijin provides process flow editors which allow an application
to be modeled visually and stored as metadata. Template-based code generators use the
metadata to generate much of the Spring configuration and implementation code. This greatly
reduces the amount of time needed to develop an application and allows detailed documentation
to be generated from the metadata.

Project Creation Wizard

(-) Creates Eclipse project structure for a Spring MVC project.
(-) Establishes classpath container for libraries expected on the application server classpath.
(-) Copies application libraries into project and adds them to the Eclipse project classpath.
(-) Generates web descriptor including Spring initializer listener/servlet and root context
    configration.
(-) Generates simple Ant build script for building WAR based on project settings.
(-) Optionally, creates an empty applicationContext.xml file and maps the file into a Spring IDE
    configuration set.

Editors

(-) Process flow editor allows for drag-and-drop creation of process flows that are translated
    into Spring MVC application flows. A single process equates to a Spring dispatcher servlet
    while the nodes within it represent Spring controllers. The process flow builder automatically
    generates the code for a DispatcherServlet subclass, prototypes for the controllers, the
    dispatcher configuration file, and the web.xml.
(-) Form editor allows forms to be designed graphically. Forms are composed of strongly-typed form
    fields that are able to populate themselves from the request. Each form field is assigned a
    converter that allows it to convert data from the request into its datatype. The Gaijin builder
    automatically generates the form bean and internal details of the form.
(-) Form validator edtor creates Spring-compatible validators for Gaijin forms. Validators are
    datatype-specific and may be chained for complex validation. Validation errors are made available
    to the request in the standard location expected by Spring taglibs.
(-) Properties files are created for each process, form and validator and are updated automatically
    from the editors. The files are merged into a reloadable message source registered in the Spring
    dispatcher configuration file. Changes to messages such as form field names and validation
    messages are reflected immediately in the application without restarting the server.
(-) Gaijin Studio is fully integrated with the Spring IDE plugins which are included in the standard
    distribution. Spring IDE configuration sets are used to specify groups of config files for both
    the root bean context and each dispatcher servlet bean context. When specifying bean references
    in the controllers, the configuration sets provide context-sensitive lists of available beans
    to choose from. The Spring IDE plugins also provide sytax highlighting of the config XML files
    and a graphical view of bean relationships.

WFNM Integration

(-) WFNM is completely integrated with the Gaijin Studio DispatcherServlet subclass. No user code
    is required to use the WFNM features. The required web descriptor entries and supporting libraries
    are added automatically. Process flow entry and exit notification are automatic as well. Objects
    added to the session within a Gaijin process are automatically re-claimed when the process is exited.
    WFNM taglibs may be used to override or enhance the default behavior.

---

Any feedback would be appreciated!

Derek Adams
dadams (at) gaijin-studio.org

Hi Derek,

Gaijin Studio for Eclipse looks really good. Are there any plans to address Spring Webflow (actually in sandbox)?

Regards

I have been looking at Spring WebFlow and am waiting to see what happens with it now that the core Spring team will have an influence on it. As it stands right now, Gaijin could generate the webflow xml file from the metadata it collects. There would have to be a couple of changes to make it compatible (like requiring a start state), but it wouldn't be much of stretch.

One problem I have with the existing implementation is that the "states" of a webflow can not be directly populated from the root context. Having to programatically pass things in via the model is not as clean as allowing dependency injection at the state level. My approach has been to have one dispatcher per process and each state (== Gaijin node) is a controller. I'm not saying this is the right solution, but it does make it easier to leverage the code that already exists for controllers by injecting the various settings (i.e. supportedMethods, cacheSeconds, etc). It also allows for injecting other data on a per-state basis, like configuring per-state permissions based on settings in the root context. In Gajin, any data that can not be passed via the context can be kept in session and automatically deleted by WFNM when the process finishes.

The plan for now is to wait and see how Spring WebFlow evolves, with the intent being to have some level of integration with it. Until then, I am going to focus on more Eclipse-oriented tasks like integration with the web tools project since that seems to be a hot topic.

Thanks for checking out Gaijin!
Derek
dadams (at) gaijin-studio.org

Quote:

---

Having to programatically pass things in via the model is not as clean as allowing dependency injection at the state level.

---

I think you are misunderstanding the use of the web flow model. The flow model contains "data", while the Spring context defines "services" (DAOs, business facades, web controllers, ...). The flow model is similar to an HTTP session: you use it to store data you are working with, but you don't use it to store references to service objects. Those service objects are passed in using DI, as you note. In a web flow, the components that interact with the services in your application are the "actions", executed in action states. Those actions are configured in a Spring application context just like any other bean, so you can let Spring inject all service objects needed by an action.

Erwin

That's what I get for posting about Spring WebFlow without actually working with it first :). Considering the new info, I am thinking that generating WebFlows from Gaijin is the right thing to do. I can update Gaijin to automatically generate everything needed for WebFlows based on the metadata it already collects from the graphical editors. The base runtime templates will have to derive from Action rather than Controller, but that is not a problem.

I know that WebFlows has been added to the Spring sandbox. Are there any major changes (API, DTD, etc) that have come out of this?

Thanks,
Derek
dadams (at) gaijin-studio.org

I looked briefly (so I might be making the same mistake you made here ... 8) ... fingers crossed) at the HelloWorld tutorial you have on your site and from what I see this is a very good match with web flows indeed! I'm looking forward to web flow integration into your tool and checking it out in detail!

Regarding the changes in "Spring 1.2 web flows" as compared to "Ervacon web flows": the concepts are exactly the same, even the DTD is very similar. The API however is quite different and more elaborate. Keep an eye on http://opensource.atlassian.com/conf...y/WEBFLOW/Home for updates. I'm going to post a "porting guide" with detailed info about the differences one of these days.

Erwin

To add on to Erwin's post, it's really evolution rather than revolution, in that all core concepts are still there, but on the other hand almost everything has been touched to refactor for better usability, more power, and other concerns. There are a number of new capabilities, such as defining flows with a Java based flow builder, as an option instead of the original XML definition. For a recent Interface21 project, we used the (new version of) the web flow lib pretty heavyly, with the Java flow builder, and it worked out quite well.

Regards,

I was just looking at the docs on the atlassian site and I'm very impressed. I had already started making a list of things that would be nice to have from a flow programming perspective. You guys covered all of them from what I can tell! I think I can convert Gaijin Studio to generate Spring Web Flow code in a couple of weeks. Expect a lot of questions from me in the meantime :)

Thanks!
Derek
dadams (at) gaijin-studio.org

gaijin-studio.org apprears to be defunct; http://sourceforge.net/projects/gaijin-studio/ instead