David Baird wrote:
On 9/27/05, Dave Howorth <[EMAIL PROTECTED]> wrote:
This is one of those moments where I haven't got a clue about the issue!
I don't understand what the done flag is for, and even less what the
requirements for _run_workflow and all its friends are. So to me it all
just seems to complicate things :(
The main thing I wanted it for was internal redirects -
internal_redirect() is like a super-template switcheroo, where you can
switcheroo the action as well. If you've completed the entire
workflow, but not yet processed the template, and something calls
internal_redirect(), internal_redirect() needs some way of knowing
whether we're still inside the workflow (in which case, just resetting
the sequence is enough to re-run a new request), or if the workflow
has been completed (in which case, internal_redirect() needs to rerun
the workflow itself).
I'm sure similar things would be possible with the current setup as well.
Well, Aaron said he wanted the done flag before the workflow changes,
but your explanation seems to be that the done flag is a detail of your
workflow implementation, so I'm still confused.
Are you talking about something like the ability to rerun handler_guts?
Something like this in handler?
my $status;
do { $status = $r->handler_guts() }
while $status == Maypole::Constants::REDIRECT;
I've got a much better idea of how the Maypole workflow works by
writing the _run_workflow stuff. One Of These Days I'll have a stab at
some of the docs.
The difficulty I have is in understanding how it is supposed to work and
be extended or modified. i.e. what's a feature, what's an implementation
detail and even sometimes what's a bug.
BTW, I like your proposed public/friend/private convention - it should
help to make things clearer. I think _parse_path should be parse_path,
though :)
FWIW, the first major change I'd like to see is the separation of
request and controller.
You know, I'm not so sure about that. I was keen on that too, until I
hacked _run_workflow(), took everything out of Maypole and put it in
phase subclasses, thought about taking _run_workflow out and putting
it in a controller class, and then I thought, how the hell do users
alter this? How do plugins alter it? So then I started making the
phases call back in to the request for things like authenticate() and
is_applicable(), and then I'm back to standard Maypole. Of course,
users could subclass the workflow/phases/controller class(es), but
that's beginning to look like a lot of trouble to go to, when we could
just have a series of overridable hooks on the request (i.e. like
authorize() and is_applicable()).
I'm confused again. The plugins and functions that you mention would be
part of the controller, not the request, surely? As would the code that
the application-developer writes (the 'driver' or 'application').
Cheers, Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Maypole-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel
