I'm not experience enought to comment on much here but you did inspire one idea
regarding template root. In short I request an interface to at least unshift
and push template paths onto the list from the Model.
It would be good to have template root be modifiable at run time by the MODEL.
Take the handheld device example -- you want a compact version of the page for
handhelds. It would get pretty tedious checking the user agent and setting the
template in every model sub.
With an interface to unshift/push template_paths onto the the list used by View
you just override the base model's process sub and check the user agent and
unshift "handheld_templates" directory onto the templates paths's list if
necessary. (That turns out to be a better separation of concerns for model subs
)
Another good use is where each user may have different skins for the app.
Or where Mozilla and IE and Konqueror don't do the same thing with the same
code, serve different templates based on user agent.
Or where you want different templates for pages with errors. Just unshift the
error_templates to front of list if an error (this may not be as practical.)
I thinks i made my point.
thanks,
--- Simon Flack <sf at flacks.net> 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
>
=====
pjs
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
_______________________________________________
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