[Catalyst] Loading template according to request path

[Richard Thomas]

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