Compared to the other stuff on this list the following seems rather
trivial. Probably I overlooked something which is already there, but
I only recently migrated my web creating toolkit from Text::Metatext
to the Template Toolkit and am still stunned by the amount of new
possibilities. My apologies in advance....
As the last migration step I am currently replacing my own directory
recursion with ttree, and while doing so two questions came up, both
concerning "relative" file names/URLs:
1) What about a plugin for URL munging?
In my templates I often want to include links to certain images or
other "global" target URLs - and I want to link "as relative as
possible".
- Links like '/images/logo.gif' fail when the resulting document
tree is read offline or mirrored to another location where
the correct link turns out to be '/~haj/images/logo.gif'.
- Links like '../images/logo.gif' are almost impossible to
maintain if the sources are in a deep directory tree - I'd have
to count the slashes in template.name to create the correct
number of '../'s.
My current solution: I wrote a very small URI plugin (as the plugin
name URL is occupied) which delegates almost everything to the
standard module URI.pm.
* I feel that a plugin for URL (or URI) munging could be of general
* interest. My current version is totally undocumented and delegates
* too much (not always taking the properties of plugin objects
* versus URI objects into account). Without promising anything
* regarding time or quality now: Am I the only one who could use such
* a plugin or should we try to define a set of useful functions?
* ....One example springs into my mind: Do you remember the question
* from the TT installation procedure:
* URL base for TT2 images? [C:/Program Files/Template Toolkit 2/images]
* I guess this could be made obsolete....
Currently I am using my plugin like that (schematic examples):
[% web_root = 'http://myserver/~me/' %]
[% USE my_uri = URI(template.name) %]
[% USE link = URI(attr.href) %]
* Get the correct relative link:
<a href="[% link.abs(my_uri.abs(web_root)).rel(web_root) %]">...
* Do something if talking about myself (e.g. if the header or
footer has a link to the actual template - I guess in the TT docs
this is accomplished by an external XML file):
<li>
[% IF my_uri.abs(web_root).eq(link.abs(my_uri.abs(web_root)) %]
<strong>apparently talking about myself</strong>
[% ELSE %]
talking about someone else
[% END %]
</li>
2) How to do "very local" INCLUDE files?
In my application ttree recurses through some directory levels,
e.g.:
${srcdir}/index.html
${srcdir}/foo/index.html
${srcdir}/foo/bar/index.html
If any of those INCLUDEs a file with [% INCLUDE baz.tt2 %] then
it is always ${srcdir}/baz.tt2 (if present), because ttree adds the
source directory to the INCLUDE_PATH. Fine, for most cases.
Now what I want is a function to INCLUDE (actually PROCESS)
${srcdir}/baz.tt2 in ${srcdir}/index.html
${srcdir}/foo/baz.tt2 in ${srcdir}/foo/index.html
${srcdir}/foo/bar/baz.tt2 in ${srcdir}/foo/bar/index.html
...without having to say, e.g. [% INCLUDE foo/bar/baz.tt2 %]
in the third case. I can't say [% INCLUDE ./bar.tt2 %] because
that refers to the current directory from which I *started*
ttree and not to anything relative to template.name.
Two ideas:
a) make use of the FILE plugin.
Problem: within the templates I don't have access to
the ttree configuration variables (as they aren't passed to the
template object). Hence I can not deduce the actual file name
behind the TT variable [% template.name %].
* Suggestion: ttree could pass its own configuration items into a
* template variable (e.g. a hash called 'ttree') of the template
* object (Obvious, but ugly workaround: 'define ttree_src=...').
Problem: I could try to [% USE File(template.name,nostat=1) %]
and then construct the "very local" include name with
[% INCLUDE "$File.dir/verylocal.tt2" %]. However, for "plain"
names like ${srcdir}/index.html the value of template.name is
'index.html' and on Win32 File.dir yields '.\' instead of the
empty string. This makes the INCLUDE statement relative to the
current directory and not to the current template.
? This could be considered a bug in the File plugin which fixes
? a directory name of './', but not '.\' (nor ':' for Mac). One
? could consider dropping fileparse (from File::Basename) in
? favour of File::Spec, which in turn does not return the file's
? extension ... before I try to supply a patch: Are there
? any opinions? (Or is it already fixed in 2.03? Sorry, forgot
? to check... still running 2.02 here...)
b) make use of the URI plugin mentioned above with 'file:' URIs
...which again could profit from having the ttree variables
available when processing the template..
--
Cheers, and many thanks to all who contribute to TT
haj
