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.
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>
--simonflk
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT