My POV is that Maypole is still young, and stability of the
interface, although nice, is still secondary to making things (even)
better. Release early and release often is the mantra, but that comes
with the responsibility of early adopters putting up with a degree of
churn in the API. Flagged by increments in the version string - maybe
we need a convention on how Maypole versions are incremented?
I'd definitely like to see the separation of controller and request.
d.
On 18 Nov 2004 at 23:59, Simon Flack wrote:
> 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
>
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
-- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk_______________________________________________ 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