Interesting solution, I am just getting up to speed on the Tiles functionality, so I wasnt aware of that functionality. I absolutely agree about the lack of componentization in html displays. Dont want to stray too far afield from struts, so Ill save my Tiles questions and comments for that dev list...
One thing though, this solution seems as much a work around as what we came up with. From an design perspective, this is a context/controller problem an not a UI rendering or client-side integration problem. It seems to me the save button "should" have a single rep. and the controller should understand the users current context for navigation/activity integration/model manipulation, whereas your solution would require combining the idea of a UI button with what happens on the backend. This is one of the reasons I think pageflow belongs in the struts framework and not as just another workflow element per se... to me it seems the controller servlet must take into account more than just the fromPage-Action-toPage notion. ----- Original Message ----- From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 12:12 PM Subject: Re: Workflow/Pageflow proposal > Paul Smith wrote: > > For example, in a recent project using struts, we had 6 different pages > > which needed to be accessed under different context. If the user came from > > page A and they had selected to transfer Record A then the save button on > > page B was supposed to do one thing. If the user came from page C then the > > save button was supposed to do another. > > This is a little off-topic, but another way to handle this is to use > Tiles definitions to create a finely-granted page. A base page can be > defined, and elements that change, like the Save button, put into their > own tiles. When you are on the the A track, the A definition uses the A > tile, on the B track, the definition uses the B tile. > > <definition name=".baseFlow" extends=".basePage"> > <put name="title" value="Workflow page" /> > <put name="form" value="/pages/workflow/SaveForm.jsp" /> > <put name="formControl" value="/pages/workflow/SaveButton.jsp" /> > </definition> > > <definition name=".workFlowA" extends=".baseFlow"> > <put name="formControl" value="/pages/workflow/A/SaveButton.jsp" > /> > </definition> > > <definition name=".workFlowB" extends=".baseFlow"> > <put name="formControl" value="/pages/workflow/B/SaveButton.jsp" > /> > </definition> > > From the application viewpoint, .workFlowA and .workFlowB are distinct > pages, but from the developers viewpoint, they are the same page with > different SaveButtons. > > Obviously, this is not presented as a omnibus solution to workflow, but > simply to point out that part of our problem is the monolithic way HTML > treats pages. In this particular example, the root problem is that there > were several "logical" pages, but they all shared a number of base > components. Of course, there are all sorts of other reasons why > workflows are important, and other workflow problems Tiles can't solve. > > -- Ted Husted, Husted dot Com > -- For priority Struts support, > -> visit http://husted.com/about/services > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
