It's a six-of-one, half-a-dozen of the other issue, but I would tend to say that the controller's job is to forward to a particular page in a particular workflow. That this page shares attributes with some other page might be a coincidence of design.
So, I kind of think that the Tiles solution is not really a workaround, but actually represents what is happening. We have two pages, each of which has it's own logical identity in the design, but (currently) share a number of attributes. Tiles lets you model exactly that circumstance. My question would be does the design require the pages to be the almost same, or that the pages just happen do almost the same thing? What would happen if one of the six workflows required a third control? When does it stop being the same page? When does the tail start wagging the dog? Another way to look at this is that the Tiles XML definition is part of the controller's workflow, at least as much as the Struts configuration is. The Tiles definition contains no real presentation logic. I could completely rewrite the HTML without touching the XML. The definition just says which logical components are needed by the page, without saying how they are rendered. The workflow engineers can build the page from individual tiles that were created by an HTML designer. A properly designed Tile can be used anyplace the engineer wants to put it. So, suddenly, it's no longer a view thing, it's a controller thing. Right now Tiles lives in the Struts contrib folder, but we are meaning to contribute it to Taglibs. But many Struts components, like the Digester and BeanUtils, live in other parts of Jakarta. -Ted. Paul Smith wrote: > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
