On 13/08/2009, at 7:56 PM, Eden Cardim wrote:
The problem with that approach is that your view is now heavily
coupled to your controller semantics. Whenever the semantics change,
you'll run into refactor hell making the template paths match.
In theory? Yes. In practice? Mmmm. The original question was about
mapping template paths to request paths. It certainly sounds like the
OP's application is like mine, very hierarchical in this sense. This
'Cascading Templates' or over-ride approach is very powerful in that
scenario.
Also, if you have arguments in your paths, say, /foo/*/bar/*, you'll
be
allowing the addition of per-record customization templates, which
leads to refactor hell once again when your underlying model changes.
Of course, this problem also exists with the traditional
template-by-action-name approach. This is why, theoretically, views
are supposed to be dispatch-agnostic and it's specifically the
controller's job to tell the view how to render data.
If you look at the original code, you'll notice the use of the $c-
>stash->{reportfolders} in the auto handler, rather than directly
referring to $c->req->path in TT.pm
This does provide a means to manipulate the template paths a bit more
to allow for arguments or special cases in the path if need be. I
didn't expand on it in the previous message, but that's the purpose of
it.
The beauty of this approach - for us, YMMV - is that the more you
componentize the templates, the more easily you can customise the
output/behaviour for certain scenarios, without resorting to templates
that look like PHP (full of display logic conditionals, etc) or adding
display code/logic to your controllers (equally horrific).
RET
______________________________________________________
Don't anthropomorphize computers. They hate that.
http://homepage.mac.com/ret
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
