On Tue, Oct 30, 2001 at 08:56:54AM -0500, darren chamberlain wrote:
> > Doesn't Apache::Template do this too?
>
> I submitted a patch a few weeks (months?) back that added that
> fucntionality.
Yes, sorry, I think I'm sitting on it.
I like the idea of being able to search up and down the INCLUDE_PATH in
various different ways. In fact, I like it so much, I want to try and
fit it into the TT core (e.g. Template::Provider). That way, we all
get to use it and it becomes available for free in Apache::Template.
I've been reading over Chuck's email, and also Darren's email from back
in June when he first raised this issue (sorry it's taken so long for
me to get around to it).
Darren said:
* For historical reasons, our HTML developers require that
files that are INCLUDEd or PROCESSed be searched for in a
tree-walking manner, starting with the directory of
$r->filename and ascending to /. This has the effect of
including the closest copy of files declared in TT2PreProcess
and TT2PostProcess, which works out very well for using a
single set of header and footer files for an entire site,
while having section specific navigation bars and features
that get included without having to specify paths and the
like.
Chuck said:
* In order to do this, each template remembers where it was
loaded from, and sets its working directory to that directory.
Templates loaded without any leading path qualifiers, which
normally causes INCLUDE_PATH to be searched in TT2 are searched
for as if INCLUDE_PATH were the current directory and every
directory above it (up to an APP_ROOT config setting that is.
Also, templates loaded with an absolute path are treated as
relative to APP_ROOT, making the whole tree relocatable.
I was thinking about allowing certain modifier metacharacters on the
end of an INCLUDE_PATH element which activate this kind of behaviour.
For example,
INCLUDE_PATH = /foo:/bar+
If the main template is 'abc/def/ghi.tt2' which gets resolved as
'/foo/abc/def/ghi.tt2' and includes a directive like [% INCLUDE xyz %]
then it should look for:
/foo/xyz
/bar/xyz
/bar/abc/xyz
/bar/abc/def/xyz
In other words, the '+' indicates that the provider should walk down
from /bar adding elements of the main template's path until a match
is found.
To walk up the path, you would use '-'. So for the same, example as
above, the INCLUDE_PATH
INCLUDE_PATH = /foo:/bar-
would try to find
/foo/xyz
/bar/abc/def/xyz
/bar/abc/xyz
/bar/xyz
Note that in both cases, the provider doesn't ever search above the
root of the INCLUDE_PATH element (e.g. /foo or /bar). I think it's
important that we keep it that way and limit such use to the ABSOLUTE
and RELATIVE options.
I'm slightly concerned that this might be a bit cryptic and may cause
problems on the offchance that someone really does have a '+' or '-'
at the end of their path. Other suggestions welcome.
Another thought is that it would be nice for the provider/document to
be able to find all possible matches so that we can introduce the
concept of pseudo-inheritance between template components. Currently,
[% component %] always gives the Template::Document for the current
template component, and so [% component.super %] (or something like that)
could be the next template that would have matched after this one
(e.g. the template of the same name one of the parent directories).
Thoughts? Comments? Suggestions?
A
