I think 'Workflow' is the wrong word here. It has many connotations, especially in the app-space I work in, that go way beyond what I have done. Working on Spindle has allowed me to understand all the "nuts and bolts" of Tapestry, but I have to admit that I don't use every feature yet in my own app. Use them as I need them and understand them.
WorkUnit is a term I coined for lack of a better one. I don't know Struts at all, but I do understand Struts users when they bring up issues with there not being a clearly defined "controller" entity in Tapestry. Our app plods happily along without WU's until a user triggers one. Then its king until it is turfed, replaced, or deactivates itself. Maybe the idea of a WU is a candidate for the contrib jar rather than Tapestry itself. But the concept would be enhanced greatly if WU's could be spec'd in XML as a flavour of component. It would be cool if they had parameters, properties, that fit the Tapestry model. Maybe a WU with its pages could be a sort of super-component. You have: WU java file WU spec that defines the pages (like in the .application file) that it uses, params, whatever then in the application you could define the WU's and thier configuration for that app. One could describe the WU+configuration as a sub-application, there are parallells when you look at it, but I like the idea of 'controller component' better. ----- Original Message ----- From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> To: "Geoff Longman" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, July 10, 2002 11:46 AM Subject: Re: [Tapestry-developer] More Controller (aka) MVC in Tapestry > I've seen a little about several workflow frameworks that could be factored > into Tapestry. > > Ultimately, I see Tapestry itself as a platform for even bigger things, such > as Servlet API is the platform for Tapestry. Automating workflow is a big > step ... that one of the reasons that I added helper beans, because those > would facilitate a lot of RAD development without resorting to Java code > generation. > > ----- Original Message ----- > From: "Geoff Longman" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 10, 2002 5:26 AM > Subject: [Tapestry-developer] More Controller (aka) MVC in Tapestry > > > > Hello Howard and the community! > > > > I have been playing around with the idea of getting more of the Controller > > in MVC while using Tapestry. > > > > We are building a large app in the telco space, many screens. I forsee > that > > even with Tapestry the > > app getting quite complex. Putting the business logic and the page > > navigation stuff in the pages themselves > > will become burdomsome to maintain as we get to 100+ pages. > > > > Our app, as most are, is divided into use-cases, each of which > collaborates > > with several pages. We are playing with the > > notion of centralizing logic for each use-case within a bean we call a > > WorkUnit (WU). At the lowest level a WU knows about the pages it > > collaorates with, has business logic, and navigation rules. > > > > I have instrumented my Engine and Visit to handle the lifecycle of WU > > Also WU's are instrumented so they can have listener methods. > > > > So, the WU is attached to the Visit and activates pages and those pages > call > > get/sets in the current WU and also call WU listener methods. The WU > > listenerMap will throw StaleLinkExceptions if a page tries to call a > > listener that does not exist, this might happen if the user used the Back > > button. A bonus of using the Tapestry propertyHelper stuff to access WU's > is > > that it is possible to share pages among WUs. > > The pages themselves a relegated to handling whatever transmorgifigcation > is > > needed to pull/push data to/from a WU, field validation etc. > > > > WU's always remember the page they last display so in the case of stale > link > > exceptions it is feasible to restore the app for the > > user to the last good page. There's lifecycle stuff too so that if, say a > > user triggered an action that would attach an different WU to the visit, > > the current WU gets a chance to examine its state and perhaps veto its > > replacement, or attach the new WU as a child. In the case of a child WU > the > > parent would lose control to the child, then regain control when the child > > is done. > > > > What I have works, but I know that it could be better and perhaps the > basis > > for a new feature for Tapestry. ie. non rendering controller components. > > > > If there is interest, I'll post a more detailed explanation on the > Tapestry > > Wiki and we can discuss. > > > > > > Geoffrey Longman > > Intelligent Works Inc. > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Two, two, TWO treats in one. > > http://thinkgeek.com/sf > > _______________________________________________ > > Tapestry-developer mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/tapestry-developer > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
