Hi, Though I'm still in the design phase of my work flow mechanism I would like to share it here as it seems you are looking for something similar.
I store a Workflow Object in ASO containing a List<Class> containing the pages to walk though, and a child WorkFlow containing a potential sub WorkFlow. I will initially populate these objects hardcoded when needed, but these could obviously come from any DataSource created at startup or page action. I have a GenericPage which all my pages extend and catches all action and form requests. It will redirect to the next page in the workflow object and remove it from the List. If there is a child WorFlow, the redirect page will be obtained from there until there are no more. This approach currently relies on using submits or action links, but can easily be altered to also work on pagelinks. I'm using a GenericPage because I already have one, but this could obviously also be achieved with a RequestFilter (or Dispatcher?? haven't looked into those yet ;-) Next to that I also will build a component to print out the workflow state giving me a generic navigation tool for all my wizards/workflows. I played with apache Shale-Dialog (with apache myfaces) for a while and liked the possibilities but found the configuration somewhat hard to get my head around. If you already have a code base that reads out your work flow config I don't think it will be hard to make this work with T5. Cheers, Joost -----Original Message----- From: Nguyen, Michael [mailto:[EMAIL PROTECTED] Sent: Thursday, November 08, 2007 12:01 PM To: Tapestry users Subject: RE: T5 how to control login state Chris/Thiago: Thanks for the responses. What I'm getting at is trying to see if it is at all possible to allow page flow control reside outside of code. The reason for this is that I don't want to have to make code changes if I want a different flow. Externalizing the workflow makes this possible. It also defines a clear path of execution for a given request. We currently have our workflows defined in XML, which is read in on applcation start. At any point in time during the execution of the workflow, I can print out it's expected route of execution. I'll know the entire decision tree up front before anything executes. Being that it is outside of code, I can view the workflow while the application is offline as well. Having a workflow engine can help differentiate code from business logic. Our current implementation resembles the State pattern I believe. Imagine this, there are a given set of instructions ( externally defined workflow); each represent an action a user can take within the application. ( ie search, open a document, etc). Each workflow can be composed of many steps or instructions. The application acts as the interpreter of the workflow. It makes no decision of its own. All it knows about is the current state of the workflow. The actions the application takes depends on the current state of the workflow. Each step ( state) defines a set of possible actions to take based upon the result of the last action which it passes to the application and which the application passes back to the workflow. By doing it this way, you can easily add new workflows without having to touch any code. For instance, you could combine a series of searches in one workflow. There are many open source workflow engines around. You can find a few at this link here: http://java-source.net/open-source/workflow-engines We currently have our own engine we implemented with our current architecture. I am trying to figure out a way to integrate it into Tapestry. As for my initial question, it seems that using the ASO mechanism you describe is the way to go for now. I agree with you that currently an answer probably lies in services. However, I'm not too familiar with Tapestry to the extent to understand how to hook up the AccessDispatcher/RequestHandler to some service that handles the redirection. I guess I need more detailed information of the request handling. From the docs, the service() methods return true or false. A true tells it processor the request has finished and false tells it to go on. After the dispatcher/requestHandler code executes what is the next dispatcher/filter in line? How can I find that out? Thanks again guys! --Michael -----Original Message----- From: Chris Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 07, 2007 2:31 PM To: Tapestry users Subject: Re: T5 how to control login state Michael, I'm pretty sure tapestry has no such mechanism. The short answer to your question is that you'd have to store these things (page names of failed/unauthorized access attempts) as an ASO, and then pull it out after logging in. I've not worked with a system like you're talking about, but am glad that T5 is lacking in XML. However something like this could probably useful, and may be doable in the form of some service. First of all I should point out the link to how you can implement a redirect exception: http://wiki.apache.org/tapestry/Tapestry5RedirectException This is a bit of a hack, but demonstrates how you can get the exception back, as well as use decoration. I think what you want is attainable through services, and probably as a dispatcher. I'll need someone with a more thorough understanding of T5 to chime in on this, especially someone that has used what you are looking for. If a dispatcher handles the request, it is responsible for sending the response (HTTP and content) to the client. With that you should have the basics for what you want. You may also have this option with RequestFilters, but I'm not sure. Anyway, someone with more knowledge on the workings would be good to hear. I'd like to know how you fare as I'm always in the market for a better way to do things. Sincerely, chris Nguyen, Michael wrote: > Thiago, > I know that on pages or components navigation is controlled by the return type. ( page class, String, etc) My question has to do with how to deal with navigation before any page or component renders. In other frameworks you can have a workflows specified outside the application in XML, a database, etc. These workflows determine page flow. In tapestry, however this is not the case that I've seen. > > I've partially implemented what Chris just posted about the Dispatcher but using the RequestFilter like Massimo suggested. What I don't know how to do is to cleanly specify where to go after logging the user in without having to manually stuff something into the HttpSession about where to return in the page flow. > > Any ideas? > > --Michael > > > > -----Original Message----- > From: Thiago H de Paula Figueiredo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 07, 2007 10:52 AM > To: Tapestry users > Subject: Re: T5 how to control login state > > On Wed, 07 Nov 2007 16:40:45 -0200, Nguyen, Michael <[EMAIL PROTECTED]> wrote: > > >> Chris, >> Is it standard >> practice in Tapestry for page redirects to throw exceptions? >> > > That's true for Tapestry 4.x, but not for Tapestry 5. > > -- > Thiago H. de Paula Figueiredo > Desenvolvedor, Instrutor e Consultor de Tecnologia Eteg Tecnologia da Informação Ltda. > http://www.eteg.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
