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]>
