Announcement Announcement Module
Collapse
No announcement yet.
Somethings to think about Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I think you are right Andy. My starting point was Struts, so I guess it was always going to look like any Web FrontController type framework.

    I've had a quick look at the article you linked and http://www.theserverside.com/article...=SpringWebFlow , and aside from the http/web focus it is very much what I am thinking off. It has some nice features I've not seen before; such as the definition of the complete flows from page to page. The syntax beats mine hands down.

    (I do find their concept of an action as a state a bit alien - Ho Hum)

    In a GUI app there could be some differences. The ability to have several frames/flows open at the same time (it may handle this - I'm not sure). The form controls that deliver something other than strings and are already validated before submission. I don't know if Spring-RCP forms are being designed with all this in mind.

    So, I'm going to do some research, a bit more thinking, and may be wait for the Spring-RCP state machine.

    Reg

    Comment


    • #17
      I also think that there is an opportunity to use Spring WebFlow (or at least these concepts) for the navigation portion of a rich client application. This makes sense, especially if we carefully separate the presentation tier from the application service tier (the guts of the application that is completely independent of what it looks like and the presentation technology being used).

      It is easy to think about an ‘application’ that is built using either a web based interface or a rich client interface that does exactly the same thing. If a navigation (state transition) engine like Spring WebFlow is useful for a web based presentation tier, then it should be also useful for a rich client based presentation tier. What has happened by doing this is that we have removed the navigation from the presentation tier and put it into the application service tier where it probably belongs.

      I do find their concept of an action as a state a bit alien
      It does seem a bit strange, but if it works so well with web applications I suspect it is right.

      I’m wondering though if the ‘command’ object would need to change a bit for this to work. It seems to me that the command object should be just an event generator, not the holder of code that does the actual work. I see the command object as one of the presentation tier objects, and by definition they shouldn’t really do much. They should simply be bound to a presentation independent service object that lives in the application service tier to do the work. Is it this service object that generates the state transitions that are managed by ‘webFlow’?

      Jim

      Comment


      • #18
        It seems to me that the command object should be just an event generator, not the holder of code that does the actual work.
        That's right. In my current application I have a single class (SwingAction) that implements java.swing.Action. The actionPerformed method on this class feeds a request to my front controller to execute the named business logic (WorkflowAction). Which is does between setting a busy cursor and displaying the correct views for the new state. It is instances of SwingAction that gets attached to buttons or used in the java.swing.ActionMap attached to a frame when a state is entered.

        Hence my utter indecision over what to call these objects (actions, commands, operations or workflow).

        Comment

        Working...
        X