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]
