Re: [Templates] properly accessing variables and content processing with TT2

> Can you give us at least an example why you have to "manage multiple

On Wed, Aug 25, 2004 at 05:57:46PM +0200, Axel Gerstmair wrote:

> Can you give us at least an example why you have to "manage multiple
> variables"? I really don't understand what exactly the problem is, so
> it's even harder to give advice.

First, "to manage multiple variables" doesn't sound very good to me neither ;)

But to stay on topic, it was about 'handling content', and more specifically,
to manipulate content (i.e. via mod_perl content handlers) inside 
the same template. 

I think this is not a problem itself, but rather it raises questions 
on how to design a quite more "dynamic template" [1]  
on some particular scenarios:

Scenario 1.  The Feminine Silk Lingerie Boutique

A user sent an initial GET to some content handler.
$stash->set() is then summoned -- containing
the results of the search -- and then the template
is processed accordingly. 

Later on, the same honorable user having seen 
something he like, (or horror, dislike ;) has sent
a new request to another content handler. That handler
do one more $stash->set statement, and then send
the back the updated template object.

        -- 

Conclusion: experiments shows that mixing content (or variables, or whatever)
inside the same "content template" may not work as expected:

- There's no way to unset stash-variables on some conditions ??
- IF/ELSIF/ELSE doesn't work very well neither with 
  that scenario because the $stash object keeps records of
  things updated along the way (precedences issues). 

> This is the same problem as with Perl's "my" and "local" variables.
> You should use private variables (declared with "my") whenever
> possible and refrain from using variables in a larger scope (declared
> with "local" or "our") because this make your code more difficult to
> maintain and more susceptible to errors. The same holds true for
> templates: if you use INCLUDE you don't have to worry about nasty
> side-effects.

Sorry for misleading again; perhaps you were refering to the $CONTEXT
global variable below? 

That one was declared as global (defined in @EXPORT and in @EXPORT_OK) 
in my package in a way that I can be lazy with Template::Context
methods.

> > sub handler {
> >     my $r = shift;
> >     my $output;
> >     my $stash = $CONTEXT->stash();               # get the stash,
> >     $stash->set('updateme', \$var);              # some content,
> >     $output .= $CONTEXT->include('header');      # does not need updating,
> >     $output .= $CONTEXT->process('content');     # but this does,
> >     $output .= $CONTEXT->include('footer');      # and this doesnt.
> >     $r->print ($output);
> > }

> Why don't you move your PROCESS and INCLUDE statements to your
> templates? It seems more natural to me to handle all the output
> formatting in the templates.

Yes.

> You said earlier:
> > The drawback is that every content/feature need
> > a separate template to be wrapped over to the site layout.
> 
> Why is this a drawback? I would even encourage using different
> template files for different contents. This way you are able to
> create modules and small reusable blocks that are easier to understand
> and maintain.

Yes, that is the same conclusion I ended up with, eventually.

> Best regards,
> Axel

Thanks,
Etienne

1. Stealing from the HTML::Mason term of "component": where a "component" can be almost anything; likewise, in terms of "content" or "template". 

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates