Actually, I'm the one who asked Paul about this feature in TA.
I don't see it as a "special case" because I'm used to do it (from
HTML::Mason). Heck, AFAIR you can do it in PHP as well. For me it's a
"special case" *not* to have this functionality—a case I have to deal with.
Anyway: Randall suggested once that I can subclass Template::Provider;
that was a good idea but I couldn't figure out in a Provider how to
detect the filename of the calling template (call me stupid if it's
obvious but I just couldn't figure it out...). As well, I can't see how
to do it using a coderef in INCLUDE_PATH. The example that Paul gave
might work but it's black magic to me—I don't want to copy/paste code I
don't understand. :)
So again, I must ask.. why can't we just have this basic functionality
in the core, instead of "you can Do It Yourself" replies? (Sorry, I
don't want to criticize, TT is really great, but there still are cases
where it's less than “ideal”, IMHO).
Cheers,
-M.
Perrin Harkins wrote:
> On Dec 11, 2007 1:18 PM, Paul Seamons <[EMAIL PROTECTED]> wrote:
>
>> If by easy you mean passing the current template object as a weakened
>> reference to the closure, attempting to find the current path, manipulating
>> the current path and adding it to INCLUDE_PATH, then you are right - it is
>> easy.
>>
>
> 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, and I don't
> think it's as complicated as you're portraying it here.
>
>
>> my @paths;
>> my $t = Template->new(INCLUDE_PATH => [EMAIL PROTECTED]);
>> my $t_copy = $t;
>> push @paths, sub {
>> # use t_copy to figure out what template we are currently in
>> my @dirs = ($dir);
>> use CGI::Ex::Dump qw(debug);
>> my $file = $t_copy->context->{LOAD_TEMPLATES}[0]{HEAD}->[1] || '';
>> unshift @dirs, $1 if $file =~ m|(.+)/[^/]+$|;
>> return [EMAIL PROTECTED];
>> };
>>
>
> 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');
>
> 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.
>
>
>> use Scalar::Util qw(weaken);
>> weaken $t_copy; # kill our circular ref
>>
>
> The template instance is nearly always in a global anyway, so I don't
> think weak refs would typically be needed here.
>
>
>> Notice having to configure with an ref to array that is later
>> populated with a reference to the tt object.
>>
>
> I don't think that needs to be so tricky either if you have a global
> or singleton template object.
>
>
>> I still think having ADD_LOCAL_PATH would be a good thing. I'm hardly
>> hurting
>> if TT doesn't add it -- but I think there are many TT users that could
>> benefit from having it.
>>
>
> And I don't represent the views of Andy or any other developer or user
> of TT2. Don't get me wrong; 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.
>
> - Perrin
>
> _______________________________________________
> templates mailing list
> [email protected]
> http://mail.template-toolkit.org/mailman/listinfo/templates
>
>
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
