Announcement Announcement Module
No announcement yet.
Gaijin Studio for Spring MVC 0.9.2 Released Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

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

  • #2
    Hi Derek,

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



    • #3
      Spring Webflow

      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!
      dadams (at)


      • #4
        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.



        • #5

          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?

          dadams (at)


          • #6
            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 for updates. I'm going to post a "porting guide" with detailed info about the differences one of these days.



            • #7
              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.



              • #8
                Very Cool!

                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

                dadams (at)


                • #9
                  Domain dead?

         apprears to be defunct; instead