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" %><% /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" %> > My Site - Articles - <$ title $> > > <$ title $>, by <$ author $> > <$ text $> > > > 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 > where everything is inserted, while leaving a <$ named_gap $> for the > contents of the central . 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: Template techniques
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" %><% /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" %> My Site - Articles - <$ title $> <$ title $>, by <$ author $> <$ text $> 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 where everything is inserted, while leaving a <$ named_gap $> for the contents of the central . 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
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: [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 -- 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
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
> > 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: 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
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. -- 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
We have done a comparison between Mason and Template Toolkit (both 1.x and 2.0). We ran several tests comparing cached and uncached components. For the tt tests, we wrote our own caching code against mysql as well as BerkeleyDB. What we discovered was that Mason is faster than tt 1.0 both cached and uncached. The big win is when moving to tt 2.0 as it is much faster. I also prefer the tt style of doing things since it is so flexible. We are going with the mysql cache - in our tests it was faster, but I know others who said BDB blew mysql away - it also fit our network architecture well. For what it's worth... Craig On Fri, 9 Jun 2000, Drew Taylor wrote: > 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)? > > >
Re: [OT now] Re: Template techniques
I'm just using XML on the backend for content management and as a way to standardize what I recieve from partners and content folks, then storing parsed content in a database from which I output text, HTML, and/or XML. XML::Parser suits quite fine for the above. So, Perl has plenty of XML support, imo. I've taken a look at what Matt is up to and I'm intrigued, but don't have a need for it as yet. Joshua, what is the itch that you are scratching if you care to opine? Ed Drew Taylor wrote: > 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 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 :) > Cool! The thing that perl is missing the most right now is XML support. > The more (and the sooner :-) packages support XML easily and natively, > the better. I'm still an XML newbie, so all this recent perl XML > development is very exciting for me! > > -- > 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
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 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 :) Cool! The thing that perl is missing the most right now is XML support. The more (and the sooner :-) packages support XML easily and natively, the better. I'm still an XML newbie, so all this recent perl XML development is very exciting for me! -- 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
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 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 :) --Joshua
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
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
Template techniques
Andy Wardley <[EMAIL PROTECTED]> wrote: > 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). 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). For the first version, I'm doing the tree thing too; a page gets compiled to an object, which is a hashref with properties; the contents themselves are stored in arrayrefs, whose elements are either scalar-refs (plain text), or element arrayrefs (method name & arguments). The reason for these scalar-refs is that it lets me clone objets by making new hashrefs, so that one object can alter the list and the other isn't affected, and at the same time keep the strings shared. The evaluation function goes through all these things, calling the methods by name, as in 'my $addtxt = $self->$method', and putting the results together. One important requirement is that no functions or callbacks are allowed to print, because there can be global filters on sections, which run at the end of evaluation. [ compiling to perl code is good ] > 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. With tree objects, I do exactly that; there's a memory cache of 30 page components using Tie::Cache, and a disk cache of compiled components, using Storable. Like Andy, I'm interested in speed too, but design, features and reliability come first. Preliminary benchmarks show that speed is quite reasonable; I'm getting 60 requests per second for a test page that calls components from 4 files (but no db connections), on my desktop PC (pIII-550 w/ Linux). My impression is that reading a compiled tree from a Storable file should be faster than compiling perl code, and that dynamic method calls aren't particularily slow either. On the other hand, compiling to perl code could remove some of the overhead in the evaluation functions, by including only the support for the things that are actually used in that component. 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?). Btw, I'm doing this for a website (www.iagora.com), and it's already stable enough that the production server runs it; I just got the approval to release it as Open Source... as soon as I find the time! I'll post a pointer here before announcing it on sites like freshmeat.net, in a week or two at most. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
[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: 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/
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]> 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 [ 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 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 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 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 C&P'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: > 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 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
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 ]
Chris Winters wrote:
>
> * [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? :)
My original question was not related to templates (I'll use embperl for
that) - the area I was trying to explore was how to read a template (all
HTML with a few in it) and the sub in the new content.
My pages usually have serveral templates - or one larger template with
comments arround iterative bits (tables) so that I end up with a main
template which may look something like:
>
and a table template:
The Designers / HTML coders I work with can then chop and change these
templates - I have made a template loader that strips the iterative
table content out into a seperate template, so that they can code a fake
entry for design reasons - and I then strip it out (looking for some
special HTML comment tags).
In a startup.pl The code then looks somat like this forgive the probably
uncompliable perl etc ... this is for explaination purposes:
use vars (MAINTMP TABLETMP);
$MAINTMP = &load('main.tmp');
$TABLETMP = &load('table.tmp');
sub load {
my $file = shift;
my $html = '';
open (TEMPLATE, $file) || die ('Cant open : ', $file, $!);
while () {
chomp;
$_ =~ s/^\s+//;
$_ =~ s/\s+$//;
$html = $html . $_;
}
close (TEMPLATE) || die ('Cant close : ', $file, $!);
return $html;
}
then in a handler:
sub makeTableContents {
# assumes @_ is a nice list in order of values
# to insert into the table ..
my $template = $TABLETMP;
my $tablehtml;
foreach (@_) {
$template ~= s//$_/;
$tableHTML .= $template;
}
return $tableHTML;
}
sub doStuff {
# assumes that it is passed in the return value from
# makeTableContents and a title
my $tableHTML = shift;
my $title = shift;
my $template = $MAINTMP;
$template =~ s//$title/;
$template =~ s//$tableHTML/;
return $template;
}
Then when I want to send it I just print the return value of doStuff
This may not be OO - but it is simplistic, and although not benchmarked,
should be fast. I have seen another OO ish implentation, that uses a
hash a bit like Mats example - this allows more flexibility as all you
need do is add the tag to the HTML, and then add the tag to the hash -
then when you do the regex it gets put in.
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 . ?
Thinking about it Mat's example is far more scalable, and reusable.
I am enjoying this thread ;-)
Greg Cope
> 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
> "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]> 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
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
* [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
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. -- 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 ) 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, 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:
Into the following Perl code:
sub handler {
my ($Response, , $__params) = @_;
$Response->Write(q||);
$Response->Write($__params{'xx-mytag'});
$Response->Write(q||);
}
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).
--
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
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 ) 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. -- 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
