Michael,
I understand what you are after, and I think you could hook in your
engine by adding a dispatcher of your own. Perhaps you could do this in
a filter as well - as long as you can access ASOs (for storing
navigational history) and control output to the client, it should be
possible. I keep hinting on dispatchers because you have response/output
control - explicit control. Or, you can simply let the response
continue. I think the method needs a bit more time to bake, but it'd
good to keep this discussion going to cover steps that people are taking
(whom are after the same thing).
Now let me quickly give my 2 cents on a couple of things. First of all I
agree that, in theory, having configs (xml, etc) outside of the proper
code is a good thing, as long as it centralizes something that benefits
from centralization, keeps the code readable, and doesn't cause a
maintenance nightmare. However in my experience such externalization
doesn't actually prevent rebuilds/redeploys because the configs often
end up in a jar or war. So if a config is changed, the app must still be
redeployed.
Regarding Joost's implementation; I the management of the navigation as
an ASO in a page which all pages must extend is, in my opinion, a bad
idea. I'm specifically talking about extending a base (page) class for
the sake of inheriting/centralizing common functionality. Yes its a
quick and easy way to accomplish what you want, and I certainly don't
want to be thought of as anti-pragmatic, but class inheritance for the
sole purpose of inheriting functionality is a misuse of inheritance.
Inheritance of functionality is a consequence, not an end. Inherit
because there is a logical parent-child/is-a relationship, not so two
classes that otherwise have nothing in common can have some common code.
Extract and isolate this common code somewhere that it belongs (like a
service). A page is a page, not a workflow engine, not an access
controller. Keep them ignorant of anything they don't need to know and
you'll find that they remain resistant and flexible in the face of
changes. I'd go as far to say that there are very few reasons one page
should extend another.
These are my thoughts. I'm glad that a couple people are after this -
there's sure to be some good hacking as a result.
sincerely,
chris
Nguyen, Michael wrote:
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]
