[Catalyst] Loading template according to request path

[Eden Cardim]

On Wed, Aug 12, 2009 at 9:58 PM, Richard Thomas<ret at mac.com> wrote:
> Matt,
>
> I don't know if any of this is useful to you. We do something that sounds a
> bit like what you're after, by tweaking the template include_path with each
> request. It's a classic path setting algorithm, working back from most
> specific to least specific location.
>
> ie, a template that says PROCESS "something.tt" that is the end result of
> the URI /myapp/xx/yy/zz will look for something.tt in tt/xx/yy/zz, then
> tt/xx/yy, then tt/xx, or tt/base. This gives us enormous flexibility to
> tweak the output at any node or leaf of the tree.
>
> You can create empty something.tt files in various places too, that has a
> negating effect.
>
> MyApp/C/Root.pm contains
>
> sub auto {
>    ...
>    $c->stash->{reportfolders} = split('/',$c->req->path);
>    ...
> }
>
> MyApp/V/TT.pm contains
>
> sub process {
>    my ($self, $c) = @_;
>    if (my $reportfolders = $c->stash->{reportfolders}) {
>        my @orig_path = @{$self->include_path};
>        my @this_path = ();
>        for my $orig_entry (@orig_path) {
>            for (my @folders = @$reportfolders; @folders; pop @folders) {
>                push @this_path, join('/', $orig_entry, '..', @folders);
>            }
>            push @this_path, $orig_entry;
>        }
>        @{$self->include_path} = @this_path;
>        #$c->log->debug(sprintf('%s:process: dynamic include_path is %s.',
> __PACKAGE__, join(':',@{$self->include_path})));
>        $self->SUPER::process($c);
>        @{$self->include_path} = @orig_path;
>    } else {
>        $self->SUPER::process($c);
>    }
> }
>
> Hope that's useful.

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. 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.

-- 
   Eden Cardim       Need help with your Catalyst or DBIx::Class project?
  Code Monkey                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://edenc.vox.com/            http://www.shadowcat.co.uk/servers/