0 Replies Latest reply on Apr 26, 2008 12:41 AM by rgustav

    PageFlow as a Component (Encapsulation)

    rgustav

      So I'm researching upgrading a framework I designed 5 years ago, which uses Struts/JSP/SFSB with an underlying a state machine driven by the SFSB.  Essentially, does a lot of the stuff that Seam w/ PageFlow can now do.  It's not as slick and shiny as Seam of course, and Seam's state management solution via scopes is quite elegant, and seems very natural to me (it's what I wish I could have had years ago).  Combine this with JSF, and I'm really going to be enjoying the future.  We won't get a huge improvement in developer productivity over our current approach, but some powerful new technical options open up simply by using Seam/JSF, etc.


      Anyway, the basic model of how we develop is to produce application components which model an entire stateful user facing business process.  Technically, these are essentially implementable as pageflows in Seam.  Every user facing process we make is such an application component, even if it contains a single state with a single initialization transition (e.g. a read-only screen w/ no interactions), consistency is nice when you've got 100s of such processes (some utterly trivial, some scarily immense).


      The part I like about how we currently approach things is the simplicity of the model we've got for the standard developer.  Everything has it's place, just following the outlined steps and you can get your work done no fuss.  The framework uses one root URL for the component, the transition/action/event being performed is clear in the URL parameters, as are other component specific additional parameters.  We also happen to define authorization on component/transition pairings too, which works slick for hiding buttons and dynamic navigation menus.  Further, at no time are any of the underlying view rendering components exposed to a user (e.g. no JSPs in URLs, etc.).


      I wish to preserve the pageflow as the primary 1st class component of our user interface development approach.  But I cannot figure out how to encapsulate the details of it's implementation in Seam.  A couple things currently escape me:


      1) How do I define a standard URL structure for a PageFlow which does not deal with the Views?  For example, it is /ApplicationProcessX in the URL
      that matters, not /SomeInternalStateView.xhtml.  From what I've found so far I need to be using URLRewrite here?  Hopefully I can write standard  rewrite rules covering every component in our system, and not require developers to do it for each component (ugh!).


      2) I cannot seem to figure out how to launch a pageflow online without going through a start-page.  I think I'd prefer to define initial transitions from a start-state (which are thoroughly documented) to tell someone the various ways for entering this flow.  The first page of the flow is the concern of the pageflow, not the caller of the pageflow, it might change over time, or worse it may be unknown until runtime (ie. a decision is required to get there).


      The ability of Seam to stitch together random Beans and Views in arbitrary order is slick.  It's just not something I wish to use everyday.  I'd prefer to have a PageFlow, with one URL, one Action/EJB, and multiple Views owned by the PageFlow.


      Has anyone else succeeded with such an approach?  Thoughts?


      Thanks!