On Mon, 12 Jun 2000, Roger Espel Llima wrote:
> The focus of my module (it'll probably be called 'iAct') is quite
> different, though.  The html-embedded command set is limited to a set of
> strictly declarative features;

You don't have to use the fancier stuff in TT.  Our designers only use
basical conditionals and looping.

> So, a file describing an article might look like this:
> 
> <% # "sticks this into an article template" %>
> <% parent src="../articles.tmpl" %>
> 
> <% # "this stuff could be multilingual, with alternate languages in the
>       same file, or not" %>
> <% section name="title" %>The Title of My Article<% /section %>
> <% section name="image" %><img src="/images/myarticle.png"><% /section %>
> <% section name="author" %>Joe Public<% /section %>
> <% section name="text" %>
> blah blah blah blah blah blah blah blah
> blah blah blah blah blah blah blah blah
> 
> The "parent" file, articles.tmpl, is the template that all such articles
> would use, and is just a set of section definitions (possibly just one),
> with gaps for the sections defined in the child.  
> 
> In the simplest case, the articles.tmpl file would be like:
> 
> <% # "the 'page' section is what goes to the browser, in the absence of a
>       'parent' declaration" %>
> <% section name="page" %>
> <html><head><title>My Site - Articles - <$ title $></title></head>
> <body>
> <h1><$ title $>, by <$ author $></h1>
> <$ text $>
> </body></html>
> 
> More realistically, the articles template would also have a parent,
> which could be the common ancestor of all the pages on the site, and
> handle all the shared navigation features, defining the main <table>
> where everything is inserted, while leaving a <$ named_gap $> for the
> contents of the central <td>.  Even more realistically, each major
> section of a site would have its own global template, defining the
> common design elements in that section, and having the global template
> as its own parent.

Honestly, I'm not trying to tell you not to write your own thing for
the pure fun of it, but this is all already available in TT.  Variable
declaration, search paths for templates, including other templates and
passing them variables, etc.  It's all there.  This is all there in Mason
as well, which recently added cool inheritance features making this kind
of thing simpler.

> To do dynamic parts, you use the <% call sub="Module::sub" %> command,

That's there to.  You can map any arbitrary function call into TT, or
write a plugin if you need object state.

> That's exactly what we were doing before: SSI-ish stuff for the
> near-static pages, and Apache::Registry scripts using CGI::FastTemplate
> for the mostly dynamic ones.

You may be aware of this already, but CGI::FastTemplate does not compile
to perl.  It uses regular expressions and parses the template every
time.  A perl compilation method will ultimately be faster.

CGI::FastTemplate should actually work fine for SSI-ish stuff, since it
doesn't cache and won't use up all your memory storing compiled perl code.

- Perrin

Reply via email to