On 9/27/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > 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.
Absolutely. Part of that I think comes from the naming of methods. is_applicable(), authorize(), additional_data() - really, they're all just hooks into different stages of the request. Another part comes from implicit changes in behaviour, depending on whether content has been generated, whether a template has been set etc. > > 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 :) Yep! > >>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'). Yes, and that's fine, but I think it potentially complicates implementations more than is necessary. I really haven't come to a view either way. The issue is really whether the code for the controller is uncoupled from other parts of the system. It may be that the controller code could live in the same package as the request. As long as the 2 domains aren't entangled in each other, there may be no need to split the code into separate packages. Or how about looking at it this way. In my code, the request and response data are actually encapsulated in HTTP::Request and HTTP::Response objects. So almost everything in Maypole.pm is controller, and talking about the Maypole 'request' is just a convention. $r is the controller, with access to separate request and response objects, and it also carries some state data about the running request. d. ------------------------------------------------------- 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
