Simon Flack:
> On Sun, 14 Nov 2004 17:47:01 +0000, Simon Flack wrote
>> Over the next week I'll take a more in-depth look at the codebase
>> and the mailing list archives and draw up a todo which I'll then
>> post to the list.
>
> Here's my view on the documentation. The manual has incomplete chapters
> (inicated on Maypole::Manual), but what is there needs to be updated
> to bring it in to line with Maypole 2.x. The API docs are pretty much
> complete, but by themselves aren't very useful. They'll be more useful
> when Maypole::Manual::Workflow is updated.
>
> And unit tests need to be written from the ground up.
Definately...
>
> Now I've pretty much stated the obvious, I need to get something off my
> chest and eat some of my words. In a previous email, I said I'd like to
> see Maypole stabilise and have few (if any) backwardly incompatible
> changes. Now, in general I'm pretty happy with the model and the view,
> but I have a bit of problem with the controller. I think there have
> been both positive and negitive developments in that area. For example,
> I like Maypole::Application but IMO, the controller is quite bloated.
> Maypole's controller has several roles fused into one object:
>
> 1. A workflow as defined in ::Manual::Workflow, which processes...
> 2. A request object which is generated by...
> 3. Platform-specific components (e.g. CGI::Maypole, Apache::MVC) *
>
> * really, these just implement specific parts of [1].
>
> All of that comes together with the magic of multiple inheritance.
>
>> From a user's point of view, I don't want to touch the workflow unless
> I really need to. I care most about setting up my data source, and
> writing templates that expose the request object. So let's see what
> we have if we split the current controller object in two:
>
> Controller:
> + config
> + debug
> + get_template_root
> + authenticate
> + exception
> + setup
> # handler
> # handler_guts
> - is_applicable
> - init
> - parse_location
> - parse_path
> - send_output
> - call_authenticate
> - call_exception
> - get_request
>
> Request object:
> + path
> + table
> + action
> + args
> + params / query
> + user
> + model_class
> + additional_data
> + objects
> + template_args
> + template
> + error
> + output
> + document_encoding
> + content_type
> [ + user ... ]
>
> I think that's a pretty clear separation of concerns. Model and view
> methods should be passed the request object. The request object needs
> to provide some access to the application configuration, possibly via
> $r->config or $r->app_class->config. Models and views shouldn't be able
> to mess about with the controller.
>
> I believe this separation will make Maypole easier to understand and
> use.
> It should also make it a lot easier to unit test.
>
> If I were writing Maypole from scratch now, I think I'd keep most of
> the
> object model as it is, but I'd certainly separate the controller from
> the request. But remember, /I/ said I want to stabilise Maypole and I
> don't really want to make sweeping API changes. I'm interested to hear
> though, what other people think about this.
>
> I've said what I came to say, now, perhaps I can sleep tonight :)
>
> </dilemma>
Funny, in Catalyst we have split the Maypole Request in Context,
Request and Response.
Some examples:
Context:
$c->config->{foo};
$c->get_request;
$c->objects->{foo} = { bar => 'yada' };
$c->trunk->{template} = 'view';
$c->session->{persistent} = 'foo';
$c->encode_uri('http://localhost/petstore/index.html?foo=bar'); #
(rewrites the given uri with sessionid if needed, so result is
http://localhost/petstore/index.html?foo=bar&sessionid=123)
...
Request (part of the context):
$c->request->headers->header('X-Bender'); # (it's a HTTP::Headers
object)
$c->request->cookies->{sessionid}->value; # (it's a CGI::Cookie or
Apache::Cookie object)
$c->request->parameters->{foo};
$c->request->arguments->[0];
$c->request->action;
...
Response (part of the context):
$c->response->headers->header('X-Bender' => 'Kiss my shiny metal ass');
# (HTTP::Headers object)
$c->response->headers->content_type('text/yaml-1.0');
$c->response->cookies->{sessionid} = { value => '123', expires => '+3m'
}; # (Can be an CGI::Cookie, Apache::Cookie object or just a hashref)
$c->response->output('Hello Maypole! :P');
$c->response->status(404);
$c->response->redirect('http://maypole.perl.org');
...
And you've managed to completely miss one point, Debugging!
Maypole needs to throw much more warnings and more verbose error
messages, debugging Maypole apps is horrible at the moment.
Thats one of the main reasons i rewrote nearly all internals for
Catalyst.
sebastian
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT