- Next »
- « Previous
«Extending Catalyst» Documentation
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.
Comments
might be a good fit. I'll try to work something in.
Thanks for the comment!
.phaylon
Does the +Full::Class::Name work everywhere? Even in catalyst.pl and such?
Things like View Helpers that are namespaced into Catalyst::* so they just work...
I'd bet that some of the things that pollute Catalyst::** are that way because people just don't realize full path names work... or that sometimes you need to use a + and sometimes you don't.
Are there any rules about what non-core things can go in Catalyst::*?
I'll ask the #catalyst-dev metamind tomorrow on this issue, but I guess it will be a list of preferable namespaces, like Catalyst::Model:: for models, Catalyst::View:: for views, Catalyst::Helper:: for helpers, Catalyst::Controller for controllers and Catalyst::Plugin for plugins. Everything else will probably go under CatalystX. I'm unsure about Catalyst::Component:: and Catalyst::Example.
I will probably add another clarifying post once I got core to agree on something and patched the docs.
Thanks again, these comments are exactly what I was looking for! :D
.phaylon
My catalyst base classes are in Mango::Catalyst::*, and since I'm not exposing any Helper magic (one will use mango.pl to create an app instead of using create.pl helper magic), everything should stay nice and tucked away in there. MyApp::* stuff just inherits from there, and since plugins can be loaded using +, all is well.
I'm surprised that create.pl doesn't JustFork with +Full::Class::Names. Maybe that's a nice TODO.