Announcement Announcement Module
Collapse
No announcement yet.
Diff Spring Web Flow and Struts Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Diff Spring Web Flow and Struts

    Can any one tell me, what is the exact diff between the application using STRUTS and Spring Web Flow ( apart from cut clear page flow in Spring SWF ).

    I already read from the article that ,

    1) The page flow in a web application is clearly visible by looking at the corresponding web flow definition (in an XML file).

    2) Web flows can be designed to be self contained. This allows you to see a part of your application as a module and reuse it in multiple situations.

    3) Web flows can define any reasonable page flow in a web application, always using the same consistent technique. You're not forced into using specialized controllers for very particular situations.

    But i couldn't get the SELF-CONTAINED concept. ( Point 2 )

    Thanks in advance...

  • #2
    Re: Diff Spring Web Flow and Struts

    Originally posted by springkarthi
    But i couldn't get the SELF-CONTAINED concept. ( Point 2 )
    Say you build a page flow to select a customer that allows you to search you existing customer base in a number of ways, allows you to create new customers, etc.

    You can reuse this page flow whenever you need to select a customer anywhere in your application, for example to create a new order, to log a phone call, to view outstanding orders, ....

    This is the concept of reuse of page flows. You write your page flow as a self-contained unit of work yet you are able to reuse this functionality anywhere without special considerations to be made.

    Comment


    • #3
      Hi,
      Thanks for replying me back.My quetion is can't we acheive the same thing using Struts.Like we can have common action classes which will be common for certain operations.

      Comment


      • #4
        Originally posted by springkarthi
        Hi,
        Thanks for replying me back.My quetion is can't we acheive the same thing using Struts.Like we can have common action classes which will be common for certain operations.
        You cannot achieve the same with Struts with so little effort. A page flow in SWF operates under one URI, including sub page flows and their sub page flows and their sub page flows and so on. SWF pauses parent page flows when a sub page flow is activated and continues its execution when the sub page flow terminates. All along state is managed by SWF meaning command objects are created, populated and disposed of within the scope of its page flow. How would you restore the state and continue navigation of one page flow when a sub page flow exits with Struts?

        Because SWF keeps track of the execution marker of managed page flows you no longer have to worry about navigation. The only thing you have to do in views is define the next state for forms and links using the _eventId parameter. You don't have to map actions to URI's or wonder if the execution of a specific action is allowed at any given moment.

        Comment


        • #5
          The main thing is page navigation decisions can be made dynamic: it's not baked in. Furthermore, you don't have to jump through hoops to make complex page navigation decisions--the framework is designed to support the non-trivial cases. Reusability and modularility are also wins: flows can embed other flows, which can embed other flows, etc.

          Flows are self-contained in the sense they have a well-defined contract for use -- you can start them and pass them input, you can tell them "something" happened, and they can produce output for you, but you cannot effect they're internals: they're black boxes. They have a lifecycle.

          In SWF, Views (clients) signal events. A web flow responds to those events to decide what to do next. The criteria for how it responds is fully configurable by you in a declarative fashion.

          You simply don't get that same capability Struts -- from your views, you bake in requests that hit a particular URL. Actions are routed those requests and they then select the next view. In webflow you just say something happened -- e.g "submit" and the flow determines what happens next, and that might invoke an complex series of processing (a chain of stuff) before returning control to the client. The flow itself is the controller--a powerful one ... what it decides to do "next" on the occurence of any event does not have to be deterministic: it can be dynamic!

          The whole lifecycle management aspect is not handed by Struts because Struts has no first-class "flow" concept. There is simply no concept there of something that is "longer than a request but shorter than a session." A lot of business processes that involve input from the user are like that: like paying your taxes on-line, for example. Web flow makes the "flow" -- defined as an application transaction that "pauses" periodically to get input from the user-- a first class thing with a well-defined lifecycle. such, you can listen to and respond to that lifecycle, and you get automatic state management.

          I could go on... :-) The main point: webflow is a powerful controller. That's it. Use it when you need its power, use plain old controllers where you don't. You mix and match as needed in one app.

          Comment

          Working...
          X