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).
> 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.
Recently, I spotted what I think may be a key simplification in Peter
Speltz's model: the notion of completing all the validation for several
objects before letting CDBI having a sniff of any of them. That may be
usable in my situation too and may simplify the implementation. I
haven't had time to look at yet though.
FWIW, one use case for this is when creating a new object of a class
with an attrite that is another object. I can't just popup a select box,
because there're too many entries in the other table. So I think I need
a search form 'embedded' in the create form somehow to use as a
selector. It's what happens when there are errors in the search form or
in other attribute values that gives me headaches.
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
