On 9/29/05, Dave Howorth <[EMAIL PROTECTED]> wrote: > I wrote: > >>>>FWIW, the first major change I'd like to see is the separation of > >>>>request and controller. > >> 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'). > > Dave Baird wrote: > > 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. > > I look at it the other way around. I think it is better to split them > into two packages unless there's something that prevents us. I expect > splitting them will improve clarity and extensibility (subclassing). >
The main reason I'm resisting separate classes is plugins. Most plugins work by adding what are essentially accessors to the request - i.e. extra state. But some operate on the workflow e.g. authentication. Some on both. We could deal with that, if it seemed worth the effort. > > 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. > > The last clause is the point, isn't it? The running request should carry > its own state data! And two aspects of that are the input (request) and > output (response). I do like the HTTP::Request and HTTP::Response idea, > that takes us some of the way there. > > One of the things that originally drove me to want to separate the two > was my desire to build subrequests and what I called contexts. I needed > to encapsulate the state of the running request exactly - nothing > missing and nothing that wasn't part of that state - so that I could > freeze them in a session store. This is good stuff, and yes, pretty much persuades me that we should go this way. What if we packaged all that stuff in a context object, but left all the code where it is, in Maypole.pm? If a pure request is all state and no behaviour, we can store stuff on a Maypole::Context object that is nothing more than a subclass of Class::Accessor (just like Maypole::Config). 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
