While all nice and dandy, adding and removing the role to our app class
in the dev/test/prod cycle can be tedious, so here's what the author did:
Instead of consuming the role directly, the author just applies the role if
certain conditions are met.

"Oh, I know! I'll just stash a sub ref"

Stashing a sub reference is convenient. Particularly when we want to avoid
adding logic to the view.

But it also is, in the author's experience, the Catalyst's most common leak.

Just hiding the logic inside a sub reference makes our templates a lot
more readable, moves the code to where it probably belongs (the controller),
and -lets face it-, when the line between code and data starts blurring
the coder gets some sort of high.

Our closure no longer leaks. And it gets the Catalyst context as an
argument, just like our components' methods!

Truly catalyzed.

There's a lot more involving leaks and, sometimes, debugging them is
not a task for the faint of heart. Hopefully, this article provided a
starting point.

Author

Marcel "SpiceMan" Montes <spiceman@cpan.org> was categorized as
an "intermediate Perl programmer" by the Catalyst Book. He's working
on it when $reallife and @deadlines allow, and he does not
talk about himself in third person over IRC.
Join him at irc.perl.org #catalyst and irc.freenode.org #perl.