[Catalyst] [RFC] Catalyst::View::Mason improvement

Sebastian Willert willert at gmail.com
Fri Sep 8 01:18:04 CEST 2006


Hi folks,

I am an avid user of Catalyst::View::Mason for some time now and
finally got around to fixed one of the few things that annoyed me
with this view class.

For those of you, who are not familiar with CVM: a major drawback
when using it is that you can only import stashed arguments from
components in the call chain (mostly autohandlers and the 
requested component). You can access $c->stash directly from
your components, but I don't think that is something you want
to do on a regular basis.

I've hacked up a Mason plugin (see the attached .pm) that will hook
into Mason's component call logic. This plugin modifies the argument
reference for all components that are:
  - neither in the call chain (they already know about the stash),
  - nor subcomponents (which I believe should be as self-contained
    as possible and have no business in accessing the stash)
  - but expect named arguments (you could also access the arguments
    of a component via @_, and we wouldn't want to mess with that)

Due to the design of Mason, component calls are much more common
than with TT, but these restrictions should keep the performance
hit on a reasonable level.

Unfortunately modifying the argument list in a plugin is explicitly
forbidden by the HTML::Mason::Plugin documentation, but after
grokking the source of HTML::Mason::Request::comp() I couldn't see
any harm in that (the list is restored after the component finishes
and I've taken care that explicit arguments of the call will override
implicit values taken from the stash). I would appreciate if someone
familiar with the internals of Mason could have a look, though.

Now I am wondering how (and if) this plugin should be distributed.
The easiest way would be to just release it as
MasonX::Plugin::Catalyst::ImportStash (or anything similar) and
leave the setup to the user. I'd rather include it as optional
feature of Catalyst::View::Mason (or a distinct view based on it),
though, because it would cause no disruption to the original view
and could easily be enabled through a config option. Any thoughts?

And finally, I've been asking myself if it makes sense to restrict
the stash parameters that are globally available. It would be trivial
to implement and close to Mason's concept of 'allow_globals',
which is unavailable in CVM. This would increase performance and 
data encapsulation but doesn't feel quite right, somehow. But maybe
this is just my reluctance to use anything with 'global' in its name.

I'd appreciate your comments, even if Mason seems a bit of a
neglected option around here ...

Cheers,
  Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ImportStash.pm
Type: application/x-perl
Size: 2597 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060908/4d7b0a48/attachment.bin 


More information about the Catalyst mailing list