Mailing List Archive

Simon Bertrang wrote on 10/08/2008 07:28 AM:
> Hi,
> i need a way to save various kinds of information between different
> points in the request chain.
> Initially i abused the stash for this, but polluting the template with
> data not needed there or even worse, preventing things to work as
> expected, did not work out.
> The session would have been another solution but the same arguments
> apply there as for the templates.
>
> What was left:
> a) accessing $c manually to hand over the data
> b) implement a controller providing a common method
> c) writing a plugin
>

what about (d) ?

package MyApp;

sub mystuff {
my ($c, %newstuff) = @_;
my $stuff = $c->stash->{_my_stuff};
$stuff->{$_} = $newstuff{$_} for keys %newstuff;
return $stuff;
}

I find just having a reserved stash key for things I want to pass around
but not necessarily pollute my template with works pretty well.
--
Peter Karman . peter@peknet.com . http://peknet.com/


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On 8 Oct 2008, at 13:28, Simon Bertrang wrote:

> Hi,
> i need a way to save various kinds of information between different
> points in the request chain.
> Initially i abused the stash for this, but polluting the template with
> data not needed there or even worse, preventing things to work as
> expected, did not work out.
> The session would have been another solution but the same arguments
> apply there as for the templates.
>
> What was left:
> a) accessing $c manually to hand over the data
> b) implement a controller providing a common method
> c) writing a plugin
>
> I decided for the plugin as i need access to this data from many
> points
> in our applications (the controllers as well as the models use
> this information).
> So what i'm now proposing is the module Catalyst::Plugin::Memory which
> is mostly identical with the stash, except that it isn't the stash.
> It allows me to capture arguments out of the chains, use them at later
> points in the chain and access them from forwarded methods.
>
> I've attached the code i've written so far but it's not done yet. A
> few
> tests are to be written as also as documentation.
>
> But what do you think? Is it conceptually ok, do you disagree with
> the
> name (suggestions welcome) or are there any other comments i should
> take
> into account before i finish and upload this?
>
> Kind regards,
> Simon

General idea of not polluting the stash/session is good imo.

However I'm not sure what you want needs to be anything more than a
wiki/cookbook example

in MyApp.pm

use Catalyst;
use base 'Class::Data::Accessor'; # So you can have defaults/override
or local on a per request basis

__PACKAGE__->mk_classaccessors(qw/memory/)

in a controller:

sub foo : Local
{
my ($self, $c) = @_;

$c->memory->{foo} = 1;
}

Unless i've missed something thats basically what your plugin would
end up doing. (Tho my personal preference is to add many such
accessors rather than just one hash, but thats not much different)

-ash

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Oct 08, 2008 at 02:28:02PM +0200, Simon Bertrang wrote:
> Hi,
> i need a way to save various kinds of information between different
> points in the request chain.
> Initially i abused the stash for this, but polluting the template with
> data not needed there or even worse, preventing things to work as
> expected, did not work out.

Catalyst::Component::InstancePerContext sticks stuff in the stash as well,
it just picks fairly careful key names and I've never had a clash.

Basically, this is what the stash is -for-, and introducing a second thing
that means the same thing only under a different name would be wrong.

I think what you maybe want is to override template_args or whatever relevant
method in your view so that it uses %{$c->stash->{template_info}} instead of
just %{$c->stash} ?

Alternatively, Template Toolkit refuses to expose keys starting with an _
for just this purpose, so if you do

$c->stash->{_internal}{foo} = ...

then you're absolutely safe from the template accessing it.

The other thing you could do, of course, is if the data is per-controller
then use Catalyst::Component::InstancePerContext in your controllers and
then do

$self->foo($foo);

and further down $c->controller('Whatever')->foo

Thoughts on these different approaches?

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Oct 08, 2008 at 08:28:39AM -0500, Peter Karman wrote:
> Simon Bertrang wrote on 10/08/2008 07:28 AM:
> > Hi,
> > i need a way to save various kinds of information between different
> > points in the request chain.
> > Initially i abused the stash for this, but polluting the template with
> > data not needed there or even worse, preventing things to work as
> > expected, did not work out.
> > The session would have been another solution but the same arguments
> > apply there as for the templates.
> >
> > What was left:
> > a) accessing $c manually to hand over the data
> > b) implement a controller providing a common method
> > c) writing a plugin
> >
>
> what about (d) ?
>
> package MyApp;
>
> sub mystuff {
> my ($c, %newstuff) = @_;
> my $stuff = $c->stash->{_my_stuff};
> $stuff->{$_} = $newstuff{$_} for keys %newstuff;
> return $stuff;
> }
>
> I find just having a reserved stash key for things I want to pass around
> but not necessarily pollute my template with works pretty well.

Well, then i could delete that thing out of stash in end, yes. But i'm
more in favor of having it not in the stash in the first place.

Thanks for the suggestion though :-)

Regards,
Simon

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Oct 08, 2008 at 02:37:39PM +0100, Ash Berlin wrote:
>
> On 8 Oct 2008, at 13:28, Simon Bertrang wrote:
>
>> Hi,
>> i need a way to save various kinds of information between different
>> points in the request chain.
>> Initially i abused the stash for this, but polluting the template with
>> data not needed there or even worse, preventing things to work as
>> expected, did not work out.
>> The session would have been another solution but the same arguments
>> apply there as for the templates.
>>
>> What was left:
>> a) accessing $c manually to hand over the data
>> b) implement a controller providing a common method
>> c) writing a plugin
>>
>> I decided for the plugin as i need access to this data from many points
>> in our applications (the controllers as well as the models use
>> this information).
>> So what i'm now proposing is the module Catalyst::Plugin::Memory which
>> is mostly identical with the stash, except that it isn't the stash.
>> It allows me to capture arguments out of the chains, use them at later
>> points in the chain and access them from forwarded methods.
>>
>> I've attached the code i've written so far but it's not done yet. A few
>> tests are to be written as also as documentation.
>>
>> But what do you think? Is it conceptually ok, do you disagree with the
>> name (suggestions welcome) or are there any other comments i should take
>> into account before i finish and upload this?
>>
>> Kind regards,
>> Simon
>
> General idea of not polluting the stash/session is good imo.
>
> However I'm not sure what you want needs to be anything more than a
> wiki/cookbook example
>
> in MyApp.pm
>
> use Catalyst;
> use base 'Class::Data::Accessor'; # So you can have defaults/override or
> local on a per request basis
>
> __PACKAGE__->mk_classaccessors(qw/memory/)
>
> in a controller:
>
> sub foo : Local
> {
> my ($self, $c) = @_;
>
> $c->memory->{foo} = 1;
> }
>
> Unless i've missed something thats basically what your plugin would end up
> doing. (Tho my personal preference is to add many such accessors rather
> than just one hash, but thats not much different)
>

That is actually a good idea and gives me exactly what i want even
without the overhead of a plugin, thanks. That makes my suggestion
useless of course; i have obviously not looked in the wiki/cookbook for
a while.

Regards,
Simon

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Oct 08, 2008 at 03:56:08PM +0100, Matt S Trout wrote:
> On Wed, Oct 08, 2008 at 02:28:02PM +0200, Simon Bertrang wrote:
> > Hi,
> > i need a way to save various kinds of information between different
> > points in the request chain.
> > Initially i abused the stash for this, but polluting the template with
> > data not needed there or even worse, preventing things to work as
> > expected, did not work out.
>
> Catalyst::Component::InstancePerContext sticks stuff in the stash as well,
> it just picks fairly careful key names and I've never had a clash.
>
> Basically, this is what the stash is -for-, and introducing a second thing
> that means the same thing only under a different name would be wrong.
>

Well, that is in contrast what Andy Grundman wrote on perlmonks [0] and
in fact i share his view that the place where data for the view is put
shouldn't be used for application internal data.


> I think what you maybe want is to override template_args or whatever relevant
> method in your view so that it uses %{$c->stash->{template_info}} instead of
> just %{$c->stash} ?
>

That could be an option but would require even more changes i think.


> Alternatively, Template Toolkit refuses to expose keys starting with an _
> for just this purpose, so if you do
>
> $c->stash->{_internal}{foo} = ...
>
> then you're absolutely safe from the template accessing it.
>

Yep, but we switched to XSLT where everything except template and xml
are taken as parameters, so that's no directly applicable.


> The other thing you could do, of course, is if the data is per-controller
> then use Catalyst::Component::InstancePerContext in your controllers and
> then do
>
> $self->foo($foo);
>
> and further down $c->controller('Whatever')->foo
>

Wow, that is more heavy than i want it to be but interesting anyways.


> Thoughts on these different approaches?
>

I honestly think they are more like workarounds as they don't provide
the clear separation of duties i want to have.
I'm happy with ash's proposal and will go with that and see if it's
working in the long term without overhead.
For now at least my proposed plugin won't be uploaded as it's really not
as useful as i thought.

Thanks for your suggestions though, they're valuable contributions to
the discussion and provide more insight in a new context.


Regards,
Simon

[0] http://www.perlmonks.org/index.pl?node_id=476246

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On 8 Oct 2008, at 16:58, Simon Bertrang wrote:
> That is actually a good idea and gives me exactly what i want even
> without the overhead of a plugin, thanks. That makes my suggestion
> useless of course; i have obviously not looked in the wiki/cookbook
> for
> a while.
>
> Regards,
> Simon

Its not in either yet. If you like it, I suggest you add it to the
wiki and/or throw us a doc patch. :)

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

On Wed, Oct 08, 2008 at 06:11:21PM +0200, Simon Bertrang wrote:
> On Wed, Oct 08, 2008 at 03:56:08PM +0100, Matt S Trout wrote:
> > On Wed, Oct 08, 2008 at 02:28:02PM +0200, Simon Bertrang wrote:
> > > Hi,
> > > i need a way to save various kinds of information between different
> > > points in the request chain.
> > > Initially i abused the stash for this, but polluting the template with
> > > data not needed there or even worse, preventing things to work as
> > > expected, did not work out.
> >
> > Catalyst::Component::InstancePerContext sticks stuff in the stash as well,
> > it just picks fairly careful key names and I've never had a clash.
> >
> > Basically, this is what the stash is -for-, and introducing a second thing
> > that means the same thing only under a different name would be wrong.
> >
>
> Well, that is in contrast what Andy Grundman wrote on perlmonks [0] and
> in fact i share his view that the place where data for the view is put
> shouldn't be used for application internal data.
>
>
> > I think what you maybe want is to override template_args or whatever relevant
> > method in your view so that it uses %{$c->stash->{template_info}} instead of
> > just %{$c->stash} ?
> >
>
> That could be an option but would require even more changes i think.

Well, yes. But it would also achieve what you want -correctly-.

The views in my apps already tend to do this.

> > Alternatively, Template Toolkit refuses to expose keys starting with an _
> > for just this purpose, so if you do
> >
> > $c->stash->{_internal}{foo} = ...
> >
> > then you're absolutely safe from the template accessing it.
> >
>
> Yep, but we switched to XSLT where everything except template and xml
> are taken as parameters, so that's no directly applicable.

I'd argue that the XSLT view should also ignore _ keys since it's the usual
convention for apps using the (most common) TT view.

> > Thoughts on these different approaches?
> >
>
> I honestly think they are more like workarounds as they don't provide
> the clear separation of duties i want to have.

The problem here is that the view data isn't clearly separated. The stash
has always been the standard way for passing data between components.

What you're doing is a workaround for that, notwithstanding any random
perlmonks thread.

--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev