Re: Template techniques
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" % htmlheadtitleMy 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
Re: [OT now] Re: Template techniques
On Fri, 9 Jun 2000, Joshua Chamas wrote: Perrin Harkins wrote: On Fri, 9 Jun 2000, Drew Taylor wrote: I really like the fact that templates can be compiled to perl code cached. Any others besides Mason EmbPerl (and TT in the near future)? Sure: Apache::ePerl, Apache::ASP, Text::Template, and about a million unreleased modules that people wrote for their own use. (I think writing a module that does this should be a rite of passage in Perl hacking.) For my second rite of passage, I'm hacking XML::XSLT integration into Apache::ASP for realtime XSLT document rendering XML::XSLT has an interesting definition of realtime ;-) I seriously suggest you check out Sablotron from www.gingerall.com - it's an amazingly quick XSLT engine with a Perl module. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Template techniques [ newbie alert + long ]
Hi there, On Thu, 8 Jun 2000, Perrin Harkins wrote: use references for passing data. But see "Advanced Perl Programming" pages 9 (Performance Efficiency) and 44 (Using Typeglob Aliases). 73, Ged.
RE: [OT now] Re: Template techniques
For my second rite of passage, I'm hacking XML::XSLT integration into Apache::ASP for realtime XSLT document rendering with a sophisticated caching engine utilizing Tie::Cache. Moving forward, the XML buzzword seems to be just about a necessity. Take it as a sign of respect Matt :) And to add one to the list, Embperl 2.0 will also support XML and XSLT :-) Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
RE: [OT now] Re: Template techniques
Has anybody run into any Perl libraries that do XSLT transformations that are usuable? Last I looked, there was no library that implemented the spec or provided a useful API. Maybe I'm behind the times... Today, Gerald Richter [EMAIL PROTECTED] frothed and gesticulated about RE:...: For my second rite of passage, I'm hacking XML::XSLT integration into Apache::ASP for realtime XSLT document rendering with a sophisticated caching engine utilizing Tie::Cache. Moving forward, the XML buzzword seems to be just about a necessity. Take it as a sign of respect Matt :) And to add one to the list, Embperl 2.0 will also support XML and XSLT :-) Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 - -- Salon Internet http://www.salon.com/ Manager, Software and Systems "Livin' La Vida Unix!" Ian Kallen [EMAIL PROTECTED] / AIM: iankallen / Fax: (415) 354-3326
RE: [OT now] Re: Template techniques
On Sat, 10 Jun 2000, Ian Kallen wrote: Has anybody run into any Perl libraries that do XSLT transformations that are usuable? Last I looked, there was no library that implemented the spec or provided a useful API. Maybe I'm behind the times... Sablotron from http://www.gingerall.com/ - all it lacks is xsl:number, as far as I know. AxKit has full support for XSLT transformations via Sablotron. However perl users interested in server side transformations might also be interested in XPathScript. I have a new guide to XPathScript up at http://xml.sergeant.org/axkit/xpathscript/guide.dkb -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
RE: [OT now] Re: Template techniques
At 17:10 10/06/2000 +0100, Matt Sergeant wrote: On Sat, 10 Jun 2000, Ian Kallen wrote: Has anybody run into any Perl libraries that do XSLT transformations that are usuable? Last I looked, there was no library that implemented the spec or provided a useful API. Maybe I'm behind the times... Sablotron from http://www.gingerall.com/ - all it lacks is xsl:number, as far as I know. No it actually lacks pretty much more than that. Most things are roughly implemented but the devil is in the details. Controlling output is painful (through xsl:output, disable-output-escaping and friends) and other things don't work exactely as expected, leading to some teeth gnashing. There are also a few bugs in the current release. However it is moving fast and I think that it'll be stable soon enough. The biggest problem imho that might not be solved too soon is that it's string-in string-out, no support for SAX (from the Perl interface). The performance is getting much better too, though I still get better results piping through Saxon (haven't tried this in mod_perl though). -- robin b. Smoking is one of the leading causes of statistics.
Re: Template techniques
On Jun 8, 1:56pm, Perrin Harkins wrote:
Not quite. The current version uses its own system of opcodes (!) which
are implemented as closures. Compiling to perl code gives much better
performance, which is why Andy is changing this.
Yep, Perrin's right. Version 1 compiled templates to tree form. Items
in the tree were scalars (plain text) or references to directive objects
which performed some processing (like INCLUDE another template, and so
on).
This is actually pretty efficient when you have a limited directive set,
but doesn't scale very well. For version 1.00 I was more concerned
about getting it functioning correctly than running fast (it was already
an order of magnitude or two faster than Text::MetaText, the predecessor,
so I was happy). Also it was much easier to develop and evolve the toolkit
with the tree-form architecture than when compiling to Perl, so it had some
hidden benefit.
But the current alpha version of 2.00 compiles templates to Perl code. A
template like this:
[% INCLUDE header
title = "This is a test"
%]
Blah Blah Blah [% foo %]
[% INCLUDE footer %]
is compiled to something resembling
sub {
my $context = shift;
my $stash = $context-stash();
my $output = '';
$output .= $context-include('header', { title = 'This is a test' });
$output .= "\nBlah Blah Blah ";
$output .= $stash-get('foo');
return $output;
}
Apart from the benefits of speed, this also means that you can cache
compiled templates to disk (i.e. write the Perl to a file). Thus you
can run a web server directly from template components compiled to Perl
and you don't even need to load the template parser. Ideally, it should
be possible to integrate compiled TT templates with Mason components
and/or any other template form which gets compiled to Perl.
A
--
Andy Wardley [EMAIL PROTECTED] Signature regenerating. Please remain seated.
[EMAIL PROTECTED] For a good time: http://www.kfs.org/~abw/
[OT now] Re: Template techniques
Andy Wardley wrote: On Jun 8, 1:56pm, Perrin Harkins wrote: Not quite. The current version uses its own system of opcodes (!) which are implemented as closures. Compiling to perl code gives much better performance, which is why Andy is changing this. Yep, Perrin's right. Version 1 compiled templates to tree form. Items in the tree were scalars (plain text) or references to directive objects which performed some processing (like INCLUDE another template, and so on). This is actually pretty efficient when you have a limited directive set, but doesn't scale very well. For version 1.00 I was more concerned about getting it functioning correctly than running fast (it was already an order of magnitude or two faster than Text::MetaText, the predecessor, so I was happy). Also it was much easier to develop and evolve the toolkit with the tree-form architecture than when compiling to Perl, so it had some hidden benefit. I was wondering if anyone had done comparisions between some of the major templating engines. I'm thinking specifically of Template Toolkit, Mason, HTML::Template, and EmbPerl. I currently use HTML::Template, and am happy with it. But I am always open to suggestions. I really like the fact that templates can be compiled to perl code cached. Any others besides Mason EmbPerl (and TT in the near future)? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: [OT now] Re: Template techniques
On Fri, 9 Jun 2000, Drew Taylor wrote: I really like the fact that templates can be compiled to perl code cached. Any others besides Mason EmbPerl (and TT in the near future)? Sure: Apache::ePerl, Apache::ASP, Text::Template, and about a million unreleased modules that people wrote for their own use. (I think writing a module that does this should be a rite of passage in Perl hacking.) - Perrin
Re: Template techniques
On Fri, 9 Jun 2000, Roger Espel Llima wrote: I'm developping yet another toolkit for templating under mod_perl (don't flame me YET, it does things that are significantly different from Mason, Embperl and others: namely completely separation of data and code, good multilingual support, and a reverse-include-based (aka OO without code) component model). Sounds like Template Toolkit to me. Or maybe even Apache::Taco (now defunct?) which worked by calling external functions. Have fun developing it, but think long and hard before you put another templating module on CPAN. So, if there's a serious argument that compiling to perl code is better, I'm interested. So far, I'm a bit doubtful that it's worth it, esp. for a large site (where you'd spend a lot of time on the perl compilation phase, reading perl files over and over; unless someone figures a way to store bytecode?). This being mod_perl, you only have to compile the perl code once per process (or once at startup). 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 when simpler techniques like the stuff used in Apache::SSI come out ahead. - Perrin
Template techniques
On Thu, 8 Jun 2000, Greg Cope wrote: This may be veering off topic - but its been on my mind for a while now Apart from thanking Stas for his benchmark work, which I find very interesting (does he sleep ;-) - this and few few others (benchmarks) have all touched on the area of including mod_perl output within HTML. I have always wonder what everyone else is doing on this front. I usually suck a template into memory (one long line) - usually done at startup. I then create all the conent with either pushing onto an array, or .= string concatination. Finally I regex the template - looking for my tags and replave those with output. Needless to say that one page can onsists of many templates (page or inside of table (bits from tr /tr) etc ...). From Stas previous benchmarks I've preloaded the mysql driver and now usually use the "push" onto array to prepare content - Thanks Stas. Who does everyone else do it ? Can this type of operation (that everyone must do at some time) be optimised as aggressively as some of the others ? Yet still keep the abstraction between design and content. As far as I've seen, the fastest template systems are the ones that convert the template to Perl code. So that's what I do. The templates all call a method (in my case $Response-Write()) which appends to a string. If there are no exceptions (see the guide) the string is sent to the browser. If there are exceptions, I parse/send an error template with the error in the template. Of course I don't know if its the fastest possible method - I prefer to code cleanly first and worry about performance later. Much later. Clean code tends to lend itself to better performance in the long run anyway, because it's easier to optimise serious performance problems away. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Template techniques
On Thu, 8 Jun 2000, Richard L. Goerwitz wrote:
As far as I've seen, the fastest template systems are the ones that
convert the template to Perl code. So that's what I do. The templates all
call a method (in my case $Response-Write()) which appends to a
string. If there are no exceptions (see the guide) the string is sent to
the browser. If there are exceptions, I parse/send an error template with
the error in the template.
I'm trying to follow this explanation, but can't quite visualize what
you're doing. I wonder if you could perhaps post a code fragment to the
list elucidating...
Err... It's a bit complicated. I'm porting someone else's template system
from a VB environment, and it's not pretty, but basically I have a
response class with a Write method that looks like this:
sub Write {
my $self = shift;
$self-{output} .= join('', @_);
}
I then have templates that get turned from this:
htmltitlexx-mytag/title/html
Into the following Perl code:
sub handler {
my ($Response, otherobjects, $__params) = @_;
$Response-Write(q|htmltitle|);
$Response-Write($__params{'xx-mytag'});
$Response-Write(q|/title/html|);
}
And then my handler looks like:
sub handler {
my $r = shift;
# setup $Response, etc...
...
eval {
do_stuff();
}
if ($@) {
if ($@-isa('Foo')) {
# process foo exception
}
elsif ($@-isa('Bar')) {
# process bar exception
}
elsif ($@-isa('Error')) {
# error
$db-rollback();
Template-Output('error.html', text = $@-{error});
}
}
$db-commit;
$Response-Send;
return OK;
and do_stuff() calls:
Template-Output('templatefilename', %params);
But if it errors out for some reason (db fails, etc) then it gets trapped
by the exception handler, and instead of giving a 500 internal server
error, we get an nice error page which they can take massive .bmp screen
shots of and mail to their sysadmin over a 56k connection ;-)
See the guide for the exception handling class I use (or variant of).
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
Re: Template techniques
On Thu, Jun 08, 2000 at 01:48:40PM +0100, Matt Sergeant wrote: On Thu, 8 Jun 2000, Greg Cope wrote: This may be veering off topic - but its been on my mind for a while now Apart from thanking Stas for his benchmark work, which I find very interesting (does he sleep ;-) - this and few few others (benchmarks) have all touched on the area of including mod_perl output within HTML. I have always wonder what everyone else is doing on this front. I usually suck a template into memory (one long line) - usually done at startup. I then create all the conent with either pushing onto an array, or .= string concatination. Finally I regex the template - looking for my tags and replave those with output. Needless to say that one page can onsists of many templates (page or inside of table (bits from tr /tr) etc ...). From Stas previous benchmarks I've preloaded the mysql driver and now usually use the "push" onto array to prepare content - Thanks Stas. Who does everyone else do it ? Can this type of operation (that everyone must do at some time) be optimised as aggressively as some of the others ? Yet still keep the abstraction between design and content. As far as I've seen, the fastest template systems are the ones that convert the template to Perl code. So that's what I do. The templates all call a method (in my case $Response-Write()) which appends to a string. If there are no exceptions (see the guide) the string is sent to the browser. If there are exceptions, I parse/send an error template with the error in the template. I'm curious Matt, as opposed to what?, reparsing the template each run? Clearly reparsing would be a big loser in terms of performance. But what other technique could be used..., hrm.., without direct control over the pipe, I really don't think it would get too much better than this. I mean, you could yank out sections and stuff it into an array that would be like: text, coderef, coderef, text, etc. Like in an ASP template you would parse the file, grab sections between % % and eval it as a code ref, and stuff it into your array. But this would probably not work specifically in ASP's case, but you might be able to pull it off in Embperl. (Unless the array itself could also point to arrays, etc.) Overall..., I think compiling it directly makes a lot more sense in 99.999% of template languages..., otherwise you'd end up putting too many restrictions on the template language itself. Hmm..., sort of an interesting question, what ways could be utilized in order to maximize speed in template execution. I thought about this a while ago, but after the fact I have to agree with Matt..., just evaling each template as a package, or a code ref would be a lot quicker, and if you could cook up another scheme, the resulting code complexity might not pan out to be worth it. Of course I don't know if its the fastest possible method - I prefer to code cleanly first and worry about performance later. Much later. Clean code tends to lend itself to better performance in the long run anyway, because it's easier to optimise serious performance problems away. Can't really disagree with that. Clean code is 100x easier to work on later. Shane.
Re: Template techniques
On Thu, 8 Jun 2000 [EMAIL PROTECTED] wrote: As far as I've seen, the fastest template systems are the ones that convert the template to Perl code. So that's what I do. The templates all call a method (in my case $Response-Write()) which appends to a string. If there are no exceptions (see the guide) the string is sent to the browser. If there are exceptions, I parse/send an error template with the error in the template. I'm curious Matt, as opposed to what?, reparsing the template each run? Clearly reparsing would be a big loser in terms of performance. As opposed to parsing into a tree and working from that. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Template techniques
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [000608 11:07]: I'm curious Matt, as opposed to what?, reparsing the template each run? Clearly reparsing would be a big loser in terms of performance. But what other technique could be used..., hrm.., without direct control over the pipe, I really don't think it would get too much better than this. I mean, you could yank out sections and stuff it into an array that would be like: text, coderef, coderef, text, etc. Like in an ASP template you would parse the file, grab sections between % % and eval it as a code ref, and stuff it into your array. But this would probably not work specifically in ASP's case, but you might be able to pull it off in Embperl. (Unless the array itself could also point to arrays, etc.) Overall..., I think compiling it directly makes a lot more sense in 99.999% of template languages..., otherwise you'd end up putting too many restrictions on the template language itself. Hmm..., sort of an interesting question, what ways could be utilized in order to maximize speed in template execution. I thought about this a while ago, but after the fact I have to agree with Matt..., just evaling each template as a package, or a code ref would be a lot quicker, and if you could cook up another scheme, the resulting code complexity might not pan out to be worth it. The newest version of Template Toolkit (currently in alpha) supports compiling templates to perl code. See about 2/3 of the way down the the README at www.template-toolkit.org. Why reinvent the wheel? :) Chris -- Chris Winters Internet DeveloperINTES Networking [EMAIL PROTECTED]http://www.intes.net/ Integrated hardware/software solutions to make the Internet work for you.
Re: Template techniques
Chris Winters wrote: The newest version of Template Toolkit (currently in alpha) supports compiling templates to perl code. See about 2/3 of the way down the the README at www.template-toolkit.org. Why reinvent the wheel? :) Also the current stable (1.06) can do this. -- Bernhard Graf -- s p e e d l i n k . d e -- fon +49-30-28000-182 [EMAIL PROTECTED] http://www.speedlink.de fax +49-30-28000-22 y a programmer Dircksenstraße 47 D-10178 Berlin
Re: Template techniques
"Bernhard" == Bernhard Graf [EMAIL PROTECTED] writes: Bernhard Chris Winters wrote: The newest version of Template Toolkit (currently in alpha) supports compiling templates to perl code. See about 2/3 of the way down the the README at www.template-toolkit.org. Why reinvent the wheel? :) Bernhard Also the current stable (1.06) can do this. And Mason was doing this from the beginning. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Template techniques
On Thu, 8 Jun 2000, Bernhard Graf wrote: Chris Winters wrote: The newest version of Template Toolkit (currently in alpha) supports compiling templates to perl code. See about 2/3 of the way down the the README at www.template-toolkit.org. Why reinvent the wheel? :) Also the current stable (1.06) can do this. Not quite. The current version uses its own system of opcodes (!) which are implemented as closures. Compiling to perl code gives much better performance, which is why Andy is changing this. Template Toolkit rocks, and will rock even more when it has the extra speed. - Perrin
Re: Template techniques [ newbie alert + long ]
On Thu, 8 Jun 2000, Greg Cope wrote: My original question was not related to templates (I'll use embperl for that) Well, I'm confused now. You'll use Embperl for templates but you're not using Embperl for templates? - the area I was trying to explore was how to read a template (all HTML with a few !--TAGS-- in it) and the sub in the new content. Embperl would work fine for that, but it's overkill. Your substitution approach is slower than compiling to perl subs, especially since you have to load the file, but saves lots of memory and is fine for something as simple as this. Has anyone any suggestions as to speeding this up - yet keeping it simple - I have played with referances to avoid all the variable copying etc . ? Caching templates in memory would certainly help, but you'll eat up a chunk of RAM. - Perrin
Re: Template techniques [ newbie alert + long ]
Perrin Harkins wrote: On Thu, 8 Jun 2000, Greg Cope wrote: My original question was not related to templates (I'll use embperl for that) Well, I'm confused now. You'll use Embperl for templates but you're not using Embperl for templates? I use Embperl when I want a templating system - but not when using HTML templates (wrong use of names on my part) - I am refering to a template in this case as an HTML file with a few special tags. - the area I was trying to explore was how to read a template (all HTML with a few !--TAGS-- in it) and the sub in the new content. Embperl would work fine for that, but it's overkill. Your substitution approach is slower than compiling to perl subs, especially since you have to load the file, but saves lots of memory and is fine for something as simple as this. Can you enlighten me into the compiling to perl subs ? The file gets loaded once into shared memory - most (stripped) HTML files are only a few 10's of K. Also the file gets loaded once at startup - not during the request stage. Has anyone any suggestions as to speeding this up - yet keeping it simple - I have played with referances to avoid all the variable copying etc . ? Caching templates in memory would certainly help, but you'll eat up a chunk of RAM. If the html is usually reasonable in size, and the code I CP'ed strips the template into one long strip with spaces / tabs (designers making things all indented etc ..) at each end of the string - and chomp. Also the templates are modular - in that one template covers main part of the page, and other templates cover the rest. This helps contiunity in HTML design etc .. (i.e only make one changen in one place) Thanks for the input. Greg - Perrin
Re: Template techniques [ newbie alert + long ]
On Thu, 8 Jun 2000, Greg Cope wrote: - the area I was trying to explore was how to read a template (all HTML with a few !--TAGS-- in it) and the sub in the new content. Embperl would work fine for that, but it's overkill. Your substitution approach is slower than compiling to perl subs, especially since you have to load the file, but saves lots of memory and is fine for something as simple as this. Can you enlighten me into the compiling to perl subs ? It's what Matt was talking about. Your program parses the template, generates perl code that produces the correct output, evals the code, and stores the results in a sub reference which you can call whenever you want that template. The first time I ever saw this done was with ePerl, but I don't know if that was really the first. All the embedded perl systems popular around here (Embperl, Apache::ASP, Mason, etc.) use some variation on this technique. I think the world's record for most compact implementation goes to Randal for a small post you can find in the archive here: http:[EMAIL PROTECTED] The file gets loaded once into shared memory - most (stripped) HTML files are only a few 10's of K. Also the file gets loaded once at startup - not during the request stage. You probably won't get much faster than that then, no matter what you do. Just make sure your regexps are fast (maybe use "study"?) and use references for passing data. - Perrin
Re: Template techniques [ newbie alert + long ]
"Perrin" == Perrin Harkins [EMAIL PROTECTED] writes: Perrin I think the world's record for most compact implementation Perrin goes to Randal for a small post you can find in the archive here: Perrin http:[EMAIL PROTECTED] Ahh yes, Apache::Cachet (it's a cache, eh?), mostly proof of concept, aborted when I started using HTML::Mason in a serious way. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
