I like this idea, although I have a suggestion for handling this in a slightly
different manner. By using the LOOP construct to simulate namespaces, your
namespace could get polluted if using global_vars=1. That might be a desirable
benefit in some situations, but most likely it will not be desirable.
Instead, what if the value of the namespace parameter was prepended to all
variable names in the included file.
For example:
<TMPL_INCLUDE NAME="header.tmpl" NAMESPACE="header:">
where header.tmpl contains this:
<html>
<head><title><TMPL_VAR NAME="title"></title></head>
Here the variable 'title' would be changed 'header:title' at parse time. So in
order to fill in the 'title' variable, you would pass a parameter to
HTML::Template called 'header:title'.
$t->param('header:title' => 'Page Title');
You might even go so far as to create a nparam function that could take a
namespace parameter:
$t->nparam('header:', { title => 'Page Title', date => $date } );
$t->param('header:title' => 'Page Title', 'header:date' => $date);
The above 2 statements would be equivalent.
This method would only have an affect on the template parsing stage. Once a
template is cached there would be no operational difference whatsoever, since
all we did was change the names of the variables at parse time.
Another possible solution would be to add a TMPL_NAMESPACE tag to do this for
any section of your templates, not just include files.
The main drawback that I see of adding namespaces to HTML::Template, is that it
complicates the syntax. One of the reasons HTML::Template is so good because it
has kept things simple.
Just my 2 cents worth...
Cees
Quoting Hrvoje Niksic <[EMAIL PROTECTED]>:
> For some years I've been a fan of the HTML::Template templating
> language. Now that I work in Java, I've spent some time implementing
> a Java version. (I wasn't aware of Philip Tellis's version when I
> started, and I needed slightly different caching features anyway.)
>
> A colleague asked an interesting question about tmpl_includes. The
> point was, how do I make an include reusable from multiple pages? I
> answered that you could simply write a function that populated the
> template variables that the include required. A user of the include
> would be required to call the function, and that would constitute
> reusability.
>
> He objected that this could cause namespace collisions: you have to
> carefully check that the includes you're using don't use a variable
> name you'd like to use in the template. Otherwise, the filler
> function will clobber some of your variables.
>
> At first, I had no response to that. But later it occurred to me that
> HTML::Template already had a namespace facility: loops. Imagine
> having a one-element loop called NAMESPACE and a template snippet like
> this one:
>
> <tmpl_loop name=NAMESPACE>
> <tmpl_include name="myfile.tmpl">
> </tmpl_loop>
>
> The include will proceed as usual, but the variables in the include
> file will be effectively "protected" under its own namespace. This
> has the added advantage that the include's companion function doesn't
> even have to know anything about the template; it can simply return a
> hashtable which the parent will apply to the include's namespace. For
> example:
>
> $t->param(NAMESPACE => &myfile_getparams());
>
> This is all possible without changing HTML::Template. The part I
> don't like is the dummy one-element loop. Instead, it would be nice
> to be able to specify the namespace when doing the include. For
> example:
>
> <tmpl_include name="myfile.tmpl" namespace="foo">
>
> Obviously, this can be *implemented* as a one-element loop called
> "foo". But it doesn't have to be -- that is obviously up to the
> individual implementors.
>
> What do you think?
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Html-template-users mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>
-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users
