On Fri, Jun 09, 2000 at 02:23:30PM -0700, Perrin Harkins wrote:
> Sounds like Template Toolkit to me. Or maybe even Apache::Taco (now
> defunct?) which worked by calling external functions.
I haven't seen Apache::Taco, but I've read through the Template Toolkit
docs; it sure looks like a very powerful system, mapping all the usual
programming and data-handling constructs into commands embedded in text,
right up to arbitrary exception handling!
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; the main idea is that a single text
(html) file does not define *one* component, but several named sections.
The basic "page object" is in itself a stash, rather than being one
piece of text with embedded commands and an associated stash of
variables.
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.
To do dynamic parts, you use the <% call sub="Module::sub" %> command,
which loads the module if needed, calls the sub, and inserts whatever it
returned there. The sub gets passed, among others, a reference to the
current page object, on which it can act (reading and writing to
sections) through method calls similar to those of CGI::FastTemplate.
This is all integrated with a single ContentHandler, which handles
language preferences, some session stuff, reads GET/POST parameters, and
makes them accessible from <% call %>'ed modules with an API similar to
CGI.pm (minus the html generation).
> Have fun developing it, but think long and hard before you put another
> templating module on CPAN.
I'm not planning to, at least not anytime soon... the idea is to put it
on ftp, make a webpage, a mailing list, and if people get interested,
it'll go where it'll go :)
> There is a situation when compiling to perl is usually worse. When you're
> just doing simple SSI-ish stuff, with lots of unique pages, turning every
> page into a perl sub becomes a memory hog which outweighs the speed
> benefit.
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. Each side worked well, but the combination
was quickly becoming unmanageable, because then you need to develop
things both ways, to keep the site integrated. If you want dynamic
login boxes on the near-static pages, you need to write them as an
SSI-ish element; if you want your forums to share the rest of the site's
look, then you need to write templates for these things too. And
session management is spread among dozens of scripts, so you can't
easily make changes to the way it works.
The whole point of the iAct project is to have a system that works
*both* for thousands of static pages sharing a common look (in a modular
way, hence the reverse-include approach), and for "web-apps" with perl
and a database as the backend.
--
Roger Espel Llima, [EMAIL PROTECTED]
http://www.iagora.com/~espel/index.html
