[Catalyst-dev] Proposal for new module: Catalyst::Plugin::Memory

[Matt S Trout]

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/