qliphoth

The newest release of the Catalyst Manual contains a document called Extending Catalyst. This is the successor of the former WritingPlugins document, which was by now very outdated and even contained not-so-good practices. Since there's plenty of space left in this editor window, I'll give you a quick introduction to the contents of the file:

• Best Practices
  This section begins with a quick checklist of things to look out for when designing an extension to Catalyst. It continues with short discussions about namespaces, inheritance and method overriding with C3, some thoughts about tests and documentation, general maintenance issues and the use of Catalyst's context object.
• Configuration
  Here you'll find the different ways a developer can communicate with your extension and configure it. It covers action attributes, custom accessors and how to create them, and a clarification on how to access the component's configuration correctly. Especially the latter part brought up some issues in the past with people's components, since the config accessor will only hold the original data, not the one merged with the values the component got via the application (for example, through the application's configuration file).
• Implementation
  In this part of the document, the actual implementation for extensions is described, together with some small examples. It covers action classes, component base classes, specific implementation details for Controllers, Models and Views and lastly, the unfortunately often misused plugins. I'll probably post something about the issues with designing everything as plugin more elaborately another time (See the update below on this matter). The section ends with an example for the COMPONENT method.

By all means, the document itself is neither finished nor complete. It still needs work, especially on examples and more details on current best practices. If you want to contribute or have an idea of what should go in, just drop me a message. If you have questions, doubts or simply want to discuss an idea of yours, you can contact the very active community either via the mailing list or the #catalyst channel on irc.perl.org.

.phaylon

Update! bricas was faster and posted an article about plugins and imports polluting the global namespace and what you can do about it.

About two weeks ago, I started to summarise the happenings around Catalyst on the Catalyst and Catalyst-Development mailing lists as well as on CPAN. Brian Cassidy and J. Shirley helped with cleaning it up and brought a bit more structure into it.

I would like to make this a monthly thing, but I cannot promise a regular time when this will be released. A lot is happening in Catalyst land in one month and we do this just on our spare time.

You can find the summary in the Catalyst wiki, so if you'd like to contribute, fix stuff, make notes and such, please do so! It is much content but I wanted to start with a rather complete set of what was happening before we start removing the not necessary parts.

You are of course encouraged to add your own Catalyst projects to the summary, especially for branches and CPAN releases.

I'd appreciate all comments and suggestions and, of course, every contribution.

Thanks,
phaylon

Source filters are generally frowned in the Perl community. Of course, this has a reason: The filter works by reading a script line by line, doing it's transformations if it along the way. The code itself is not preparsed, although there are modules that do that for value, with more or less success. Smart::Comments is a nice example for a useful sourcefilter, since it parses comments and should only be active when developing anyway.

Yet source filters (or rather: their hooks, timings and workings) have some advantages that are hard to emulate. I just started experimenting with this, so I'll focus on two particular niceties I'm currently abusing:

Execute code between a package's compile- and runtime

A sourcefilter will be running while a package is compiled, and it will know when it reached the end of the file. This allows the filter to execute his code after the compiletime of the package that is use'ing it. I've already implemented and released Filter::EOF, which allows you to execute a callback in that moment. The following release of namespace::clean makes use of this and removes your imported functions. This means that you can import and call functions in your package, but they won't be available as methods.

Inject code at the use line or the end of the file

Normally, filters are used to change source code below their use line. This is of course not suitable for production and can make a lot of problems. But it doesn't need to change the code itself. It can also prepend or append its own code to the filtered one. I will use this inlining feature for closure signatures and inline argument validation soon. I'll probably also release a filter that makes this kind of injection easier.

Conclusion

While it is a common and good practice to avoid source filters in general for production environments, some of the side effects of their implementation can be used for pretty awesome stuff. So please don't lynch me if I release some more modules making use of them to the CPAN :)