> I would probably do it by overriding Template::Document::process, but
> the INCLUDE_PATH coderef hack was added to allow people to do path
> manipulations that might not appeal to all users and,
Yes, TT is extremely modular and can be hacked many different ways.
Substituting a custom provider would probably work very well - or
Template::Document, or Template::Context. It is possible to hack just about
any amount of functionality in given enough time and effort.
> and I don't
> think it's as complicated as you're portraying it here.
Actually I think I simplified it - it actually can't be done properly without
substituting one of the Template classes with a custom one. I cheated and
poked at the internals - there is no guarantee that they would always be
consistent.
> As the FAQ says, you can always get the current template from
> "component" in the stash. So, you'd do something like this to get it:
> $t->service->context->stash->get('component');
Yes - you can - but the dir of the filename is only relative to INCLUDE_PATH.
For security reasons it is impossible to get access to the actual file used.
So, using component could work if you only have 1 INCLUDE_PATH, but would be
buggy if you had 2 or more. You'd have to add a version of the relative path
for each existing INCLUDE_PATH - and if you nested an include you'd quickly
start increasing the number of paths (3 becomes 6 becomes 12 etc).
> I suspect there are cases where the template has no file path though
> (because it was created in some other way), and I'm not sure what
> behavior people would want to fall back to there.
The current ADD_LOCAL_PATH option of Template::Alloy does nothing as doing
nothing is what makes sense.
> The template instance is nearly always in a global anyway, so I don't
> think weak refs would typically be needed here.
> I don't think that needs to be so tricky either if you have a global
> or singleton template object.
Using globals sometimes, sure - but "nearly always"? Ick. Only my persistent
TT or TA object in a mod_perl situation has ever been global - I hardly ever
use a global TT otherwise. Having to use a global doesn't seem like a good
solution (though it is arguably better than the hacked solution I threw
together on the last post). In any case, it would be non-trivial for anybody
to implement without modifying TT directly because ADD_LOCAL_PATH needs to
only be in effect during the processing of a template or subtemplate - the
changes to path have to automatically undo when the process is done or an
error is thrown.
> I see that it's not easy for a casual
> user. I'm just looking for a way to handle what sounds like a special
> case through a general mechanism created to allow for special cases.
Arguably it is a special case - but there have been half a dozen recorded
requests for that feature on this list or perlmonks since I've been receiving
this mailing list. There are probably more who have read those posts and
more who didn't even know where to look. It probably still is special case.
However, I think that it would become not-special-case if it were actually
easy to do.
I'm sorry to belabor the issue. I won't anymore. Template::Alloy does it. I
think it would be nice if TT did to. People have requested it multiple
times. It can't be done without a core TT module override.
Paul
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
