[Catalyst] template design issue: varibales stand-alone components

[Gene Selkov]

On Wed, 4 Feb 2009, J. Shirley wrote:

> The Catalyst method is quite simple, since it tries to adhere to the
> MVC design patterns.
>
> You would not set the variable in your templates, instead in the controller.
>
> sub action_name : Local {
>    my ( $self, $c ) = @_;
>   $c->stash->{surname} = $c->model('LDAP')->get_ldap_surname($id);
> }
>
> Then your template gets 'surname' and you can just do:
>
> Hello <% $surname %>!

I understood as much. The problem I am grappling with is the complexity of 
the web pages I have to present, with many different states and 
transitions. There is no way I can code for that with a single template.

I am used to the idea that I can have a parent template (autohandler in 
Mason), which provides basic navigation and status display for the site; 
autohandler then invokes another template (a master template for that 
particual page's content) which itself uses various odd templates for 
recurrent elements in the page, and the change of state sometimes consists 
of replacing one little component of a sub-component with a component of a 
totally different nature (say, a name is replace with a list of names, or 
a blank display component is replaced with a message resulting from a 
prior action).

Mason seems to be perfect for that; I have built a fairly complicated 
site, and succeeded in making it look simple for the user, but it is an 
ugly mess within. It's enough for me to spend a month without doing 
something with it that I forget how it works. Even worse, I have to pass 
the project on to someone, and before that happens, I want to achieve some 
transparent architecture that a stranger can navigate and understand. 
Having done some minor work in Catalyst on other projects, I have high 
expectations. But I don't have a clear vision of how such recursive 
templating will play out in Catalyst.

If I understood the Catalyst model correctly, I will need some sort 
of nested views. Or am I complicating the problem beyond necessity? How 
else can I achieve mutable views with a hierachy of sub-views?


Thanks,

--Gene