Mailing List Archive: Catalyst: Users

context in ::V::TT::new()

Index | Next | Previous | View Threaded

mdrichardsatgmail.com

Jul 18, 2005, 9:40 PM

Post #1 of 12 (390 views)
Permalink

context in ::V::TT::new()

Hello,

I'm overriding the new subroutine in a Template Toolkit as
described in Tutorial.pod in the "Hooking in to Template Toolkit"
section. Is it possible to access the context object from here? I'd
like to get to the stash to figure out which wrapper template to use
but it doesn't see that the context object exists here. Any tips or
pointers would be greatly appreciated.

Thank you,
Michael

sriatoook.de

Jul 18, 2005, 11:23 PM

Post #2 of 12 (380 views)
Permalink

context in ::V::TT::new() [In reply to]

Am 18.07.2005 um 21:42 schrieb Michael Richards:

> Hello,
>
> I'm overriding the new subroutine in a Template Toolkit as
> described in Tutorial.pod in the "Hooking in to Template Toolkit"
> section. Is it possible to access the context object from here? I'd
> like to get to the stash to figure out which wrapper template to use
> but it doesn't see that the context object exists here. Any tips or
> pointers would be greatly appreciated.

new() gets called on app startup...there is no context at that time. ;)
If you need a global context object at runtime there's always
Catalyst::Plugin::Singleton.

--
sebastian

paradawksatgmail.com

Jul 18, 2005, 11:53 PM

Post #3 of 12 (382 views)
Permalink

context in ::V::TT::new() [In reply to]

I needed similar functionality - changing INCLUDE_PATH based on part
of the URL. I ended up copying the Catalyst::View::TT code into a
view for the application and moved the bulk of the new() code into
process() where the context is available. It's less efficient,
obviously, but it's working for me. I haven't profiled it yet to see
what the impact is.

Todd

On 7/18/05, Michael Richards <mdrichards [at] gmail> wrote:
> Hello,
>
> I'm overriding the new subroutine in a Template Toolkit as
> described in Tutorial.pod in the "Hooking in to Template Toolkit"
> section. Is it possible to access the context object from here? I'd
> like to get to the stash to figure out which wrapper template to use
> but it doesn't see that the context object exists here. Any tips or
> pointers would be greatly appreciated.
>
> Thank you,
> Michael
>
> _______________________________________________
> Catalyst mailing list
> Catalyst [at] lists
> http://lists.rawmode.org/mailman/listinfo/catalyst
>

--
Todd
--
Todd Holbrook
Systems Consultant
Simon Fraser University

perrinatelem.com

Jul 19, 2005, 12:00 AM

Post #4 of 12 (387 views)
Permalink

context in ::V::TT::new() [In reply to]

On Mon, 2005-07-18 at 14:55 -0700, Todd Holbrook wrote:
> I needed similar functionality - changing INCLUDE_PATH based on part
> of the URL. I ended up copying the Catalyst::View::TT code into a
> view for the application and moved the bulk of the new() code into
> process() where the context is available. It's less efficient,
> obviously, but it's working for me. I haven't profiled it yet to see
> what the impact is.

You're calling Template->new() on every request? Don't do that. It's a
big performance hit (you are basically turning off caching) and is not
required just to change the include path. Check the Template Toolkit
list archives (or the Maypole ones) for examples of modifying the
include path.

- Perrin

mdrichardsatgmail.com

Jul 19, 2005, 12:33 AM

Post #5 of 12 (384 views)
Permalink

context in ::V::TT::new() [In reply to]

On 7/18/05, Sebastian Riedel <sri [at] oook> wrote:
>
> Am 18.07.2005 um 21:42 schrieb Michael Richards:
>
> > Hello,
> >
> > I'm overriding the new subroutine in a Template Toolkit as
> > described in Tutorial.pod in the "Hooking in to Template Toolkit"
> > section. Is it possible to access the context object from here? I'd
> > like to get to the stash to figure out which wrapper template to use
> > but it doesn't see that the context object exists here. Any tips or
> > pointers would be greatly appreciated.
>
> new() gets called on app startup...there is no context at that time. ;)
> If you need a global context object at runtime there's always
> Catalyst::Plugin::Singleton.

Ahh, of course. That makes perfect sense.

Thank you.

paradawksatgmail.com

Jul 19, 2005, 12:49 AM

Post #6 of 12 (386 views)
Permalink

context in ::V::TT::new() [In reply to]

I hadn't checked to see what the performance hit was, but I'll trust
Perrin's "don't do that". I'm not sure if access to WRAPPER is
available in the same way, but this seems to work for my INCLUDE_PATH
problem. It's probably not the "right" solution, but after attempting
to search the various mail lists without coming up with a definitive
solution I went with this (which is basically stolen from
CGI::Application::Plugin::TT). If someone does have a definitive
solution, I (and others, I'm sure) would love to see it on the wiki.

In App::View::TT which uses Catalyst::View::TT as a base:

sub process {
my $self = shift;
my $c = shift;
my $root = $c->config->{root};
$self->template->context->load_templates->[0]->include_path([$c->stash->{extra_include_dir},
$root, "$root/base"]);
$self->SUPER::process($c, @_);
}

Actually, after preparing this I discovered I may not be able to use
this after all without doing some other changes as it doesn't pick up
when a template has been deleted. I guess it keeps serving it out of
a cache. Unfortunately my application has a separate maintenance
system that allows (trusted) administrators to modify/delete templates
using a web tool.
--
Todd Holbrook
Systems Consultant
Simon Fraser University

boy.maasatgmail.com

Jul 19, 2005, 12:07 PM

Post #7 of 12 (381 views)
Permalink

context in ::V::TT::new() [In reply to]

You can also supply a subroutine ref to fill in the include path using
the Template Toolkit. This subroutine can use fe a package variable to
supply a per request include path.

my @INC_TT;

sub set_inc_path { @INC_TT = @_ }
sub get_inc_path { \@INC_TT }

__PACKAGE__->config(
DEBUG => Battles->debug ? DEBUG_PROVIDER : undef,
INCLUDE_PATH => [ \&get_inc_path ]
);

-Boy

Todd Holbrook wrote:

>I hadn't checked to see what the performance hit was, but I'll trust
>Perrin's "don't do that". I'm not sure if access to WRAPPER is
>available in the same way, but this seems to work for my INCLUDE_PATH
>problem. It's probably not the "right" solution, but after attempting
>to search the various mail lists without coming up with a definitive
>solution I went with this (which is basically stolen from
>CGI::Application::Plugin::TT). If someone does have a definitive
>solution, I (and others, I'm sure) would love to see it on the wiki.
>
>In App::View::TT which uses Catalyst::View::TT as a base:
>
>sub process {
> my $self = shift;
> my $c = shift;
> my $root = $c->config->{root};
> $self->template->context->load_templates->[0]->include_path([$c->stash->{extra_include_dir},
>$root, "$root/base"]);
> $self->SUPER::process($c, @_);
>}
>
>Actually, after preparing this I discovered I may not be able to use
>this after all without doing some other changes as it doesn't pick up
>when a template has been deleted. I guess it keeps serving it out of
>a cache. Unfortunately my application has a separate maintenance
>system that allows (trusted) administrators to modify/delete templates
>using a web tool.
>--
>Todd Holbrook
>Systems Consultant
>Simon Fraser University
>
>_______________________________________________
>Catalyst mailing list
>Catalyst [at] lists
>http://lists.rawmode.org/mailman/listinfo/catalyst
>
>
>

luke.saundersatgmail.com

Jul 19, 2005, 3:28 PM

Post #8 of 12 (381 views)
Permalink

context in ::V::TT::new() [In reply to]

Somewhat off topic: It seems to me that it might be useful to have
some sort of context like object available at app start. Currently the
only place to store objects at that level is in MyApp->Config though
that seems unclean to me as objects stored may not be config related.
Another reason for some sort of app level object is to have access to
some debug methods (like $c->log->debug) before a request is made.

One of the next things on my list is to look into Catalyst plugins and
what they are capable of, so it maybe that I could achieve what I want
by writing one of those.

Would be interested to hear your thoughts.

Luke.

On 7/18/05, Sebastian Riedel <sri [at] oook> wrote:
>
> Am 18.07.2005 um 21:42 schrieb Michael Richards:
>
> > Hello,
> >
> > I'm overriding the new subroutine in a Template Toolkit as
> > described in Tutorial.pod in the "Hooking in to Template Toolkit"
> > section. Is it possible to access the context object from here? I'd
> > like to get to the stash to figure out which wrapper template to use
> > but it doesn't see that the context object exists here. Any tips or
> > pointers would be greatly appreciated.
>
> new() gets called on app startup...there is no context at that time. ;)
> If you need a global context object at runtime there's always
> Catalyst::Plugin::Singleton.
>
> --
> sebastian
>
>
> _______________________________________________
> Catalyst mailing list
> Catalyst [at] lists
> http://lists.rawmode.org/mailman/listinfo/catalyst
>

sriatoook.de

Jul 19, 2005, 5:26 PM

Post #9 of 12 (382 views)
Permalink

context in ::V::TT::new() [In reply to]

Am 19.07.2005 um 15:31 schrieb luke saunders:

> Somewhat off topic: It seems to me that it might be useful to have
> some sort of context like object available at app start. Currently the
> only place to store objects at that level is in MyApp->Config though
> that seems unclean to me as objects stored may not be config related.
> Another reason for some sort of app level object is to have access to
> some debug methods (like $c->log->debug) before a request is made.
>
> One of the next things on my list is to look into Catalyst plugins and
> what they are capable of, so it maybe that I could achieve what I want
> by writing one of those.
>
> Would be interested to hear your thoughts.

Just add class data to you app class.

MyApp->mk_classdata('foo');
MyApp->foo($someobject);

The new pod on writing plugins should make it a bit more clear.
http://dev.catalyst.perl.org/file/trunk/Catalyst/lib/Catalyst/Manual/
WritingPlugins.pod

perrinatelem.com

Jul 19, 2005, 8:49 PM

Post #10 of 12 (381 views)
Permalink

context in ::V::TT::new() [In reply to]

On Tue, 2005-07-19 at 12:09 +0200, KXCG Maas wrote:
> You can also supply a subroutine ref to fill in the include path using
> the Template Toolkit.

That will work.

> Todd Holbrook wrote:
>
> >I hadn't checked to see what the performance hit was, but I'll trust
> >Perrin's "don't do that".

Jesse Sheidlower saw about an order of magnitude performance difference
with Maypole when using caching, but it depends a lot on the complexity
of your templates.

> >sub process {
> > my $self = shift;
> > my $c = shift;
> > my $root = $c->config->{root};
> > $self->template->context->load_templates->[0]->include_path([$c->stash->{extra_include_dir},
> >$root, "$root/base"]);
> > $self->SUPER::process($c, @_);
> >}

That will work fine as well.

> >Actually, after preparing this I discovered I may not be able to use
> >this after all without doing some other changes as it doesn't pick up
> >when a template has been deleted. I guess it keeps serving it out of
> >a cache. Unfortunately my application has a separate maintenance
> >system that allows (trusted) administrators to modify/delete templates
> >using a web tool.

It might not catch deletes. It does catch modifications. If deletes
happen often and you need them to be reflected immediately, you could
subclass the Template::Provider to check for that. (I think that's the
right class. Might be worth asking on the TT list to see if anyone did
this already.)

- Perrin

luke.saundersatgmail.com

Jul 19, 2005, 9:39 PM

Post #11 of 12 (380 views)
Permalink

context in ::V::TT::new() [In reply to]

Looks good. Thanks for that.

On 7/19/05, Sebastian Riedel <sri [at] oook> wrote:
>
> Am 19.07.2005 um 15:31 schrieb luke saunders:
>
> > Somewhat off topic: It seems to me that it might be useful to have
> > some sort of context like object available at app start. Currently the
> > only place to store objects at that level is in MyApp->Config though
> > that seems unclean to me as objects stored may not be config related.
> > Another reason for some sort of app level object is to have access to
> > some debug methods (like $c->log->debug) before a request is made.
> >
> > One of the next things on my list is to look into Catalyst plugins and
> > what they are capable of, so it maybe that I could achieve what I want
> > by writing one of those.
> >
> > Would be interested to hear your thoughts.
>
> Just add class data to you app class.
>
> MyApp->mk_classdata('foo');
> MyApp->foo($someobject);
>
> The new pod on writing plugins should make it a bit more clear.
> http://dev.catalyst.perl.org/file/trunk/Catalyst/lib/Catalyst/Manual/
> WritingPlugins.pod
>
> _______________________________________________
> Catalyst mailing list
> Catalyst [at] lists
> http://lists.rawmode.org/mailman/listinfo/catalyst
>

paradawksatgmail.com

Jul 19, 2005, 9:58 PM

Post #12 of 12 (380 views)
Permalink

context in ::V::TT::new() [In reply to]

On 7/19/05, Perrin Harkins <perrin [at] elem> wrote:

> snip <

> > >Actually, after preparing this I discovered I may not be able to use
> > >this after all without doing some other changes as it doesn't pick up
> > >when a template has been deleted. I guess it keeps serving it out of
> > >a cache. Unfortunately my application has a separate maintenance
> > >system that allows (trusted) administrators to modify/delete templates
> > >using a web tool.
>
> It might not catch deletes. It does catch modifications. If deletes
> happen often and you need them to be reflected immediately, you could
> subclass the Template::Provider to check for that. (I think that's the
> right class. Might be worth asking on the TT list to see if anyone did
> this already.)

Thanks, Perrin, that's exactly what I did this morning. It involved
subclassing Template::Provider to rewrite part of _fetch_path() and
then making sure Catalyst::View::TT was using the new Provider. I
found a partial solution on the TT list, but it only worked after the
template was hit twice and didn't seem to clean up the doubly linked
list properly.

Todd
--
Todd Holbrook
Systems Consultant
Simon Fraser University

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads