Feature Proposal: Do We Really Need That Many Ways To Find Templates?

Motivation

We currently have two systems in the DakarRelease to customize templates:

1. The algorithm for template lookup (in TemplateDotPm) allows for a wide variety of locations of the template to be applied:
   1. looks for file $name.$skin.tmpl (for each skin)
      1. in templates/$web
      2. in templates, look for
   2. looks for file $name.tmpl
      1. in templates/$web
      2. in templates, look for
   3. if a template is not found, tries in this order
      1. parse $name into a web name (default to $web) and a topic name and looks for this topic
      2. looks for topic ${skin}Skin${name}Template
         1. in $web (for each skin)
         2. in TWiki::cfg{SystemWebName} (for each skin)
      3. looks for topic ${name}Template
         1. in $web (for each skin)
         2. in TWiki::cfg{SystemWebName} (for each skin)
2. SupportTopicSpecificTemplates provides support for custom view templates on a per-topic basis.

Is it really necessary to have that many ways of finding a template? These variations might be more confusing than it is worth...

What do we need at a minimum?

• A set of generic templates applicable system wide
• A set of templates for each skin applicable system wide
• Topic-specific view templates
• (Maybe) topic-specific edit templates
• (Maybe) web-specific view and edit templates

I have yet to see situations that would require web-specific sets of templates or web-specific alterations to a skin. Admittedly, I had used these in the past to support custom applications, but those situations are much better handled with topic-specific templates.

Description

Consider simplification of the template lookup function.

-- ThomasWeigert - 10 Jul 2005

Impact and Available Solutions

Documentation

Examples

Implementation

Discussion:

Actually, this proposal should be TooManyTemplateLookups. Templates change much too infrequentt to make the template-lookup a completely dynamic one. Like hardware detection. Shouldn't happen on every bootup but only on demand.

-- MichaelDaum - 10 Jul 2005

This is a good topic to start discussing something I've been thinking about for a long time; compiled templates.

Where TemplateToolkit really scores is in the precompilation of templates. They take the basic template text and convert it into a Perl program. That way, expanding the template is simply a case of executing the Perl code. The Perl is cached, and refreshed if the original template text is changed.

It seems to me that this kind of strategy wouldn't be too hard to do. You could even do it statically, and only support template compilation from configure.

-- CrawfordCurrie - 10 Jul 2005

CC, your thoughts go in the right direction. But before proposing template compilation, i'd like to now exacly where we are in dakar now and what the different escalations are to improve the speed of the template speed. So here's a wild rant with no specific order on what is involved:

1. all TMPL macros are processed on every requests (status quo)
2. each INCLUDE is fetched from disk on every request (status quo)
3. DEFs are hashed and kept for the duration of one request (status quo)
4. INCLUDEs are hashed (???)
5. DEFs and INCLUDEs hashes are serialized into a cache
6. complete templates are expanded and serialized into a cached
7. a template cache should only be invalidated manually
8. if there's no (template) cache it gets rebuilt automatically
9. templates are compiled into a perl module returning its cargo on a getit() call

Using mod_perl allows to keep template hashes in memory for more than one request obviously. But the template engine should be as fast as possible even w/o mod_perl.

Then the places to look for templates will only slow down rebuilding the template cache thereby easing the request.

-- MichaelDaum - 10 Jul 2005

Moving one-time functionality to configure - or to some similar configuration step - is the only way I can find to squeeze more performance. Michael, your assessment of the status quo is AFAIK correct. But bear in mind that template loading is only a fraction of runtime. It's far outweighed by compilation time.

-- CrawfordCurrie - 10 Jul 2005

Yes, I think so too. So it is not worth it. A fortiori when there was content caching.

-- MichaelDaum - 10 Jul 2005

Dropping from DakarRelease.

-- CrawfordCurrie - 11 Jul 2005