Day 24 - The Catalyst Community

A round up of what's where in the Catalyst community.


Any active open source project is as much about the community surrounding the software as the software itself. A useful and wonderful piece of software is of much less use with an unresponsive community. This short article outlines what is where and who in the Catalyst community.

The subversion repository.

You can get everything catalyst from the project subversion repository: At present there are about 115 people with write access to the repository, and about 15 of whom have write access to everything there. The repository is fairly sizable (a little under 350MB at the moment), with the standard tags branches trunk sections. Because it can lead to breakage later on if you don't it's generally a good idea to check out the whole repository from the top first. i.e.

 $ svn co

or with svk (checking out the whole repository initially is of particular importance for svk):

 $ svk mirror //mirror/Catalyst
 $ svk sync -r HEAD //mirror/Catalyst
 $ svk co //mirror/Catalyst

Mailing lists

There are two Catalyst mailing lists, Catalyst Users and Catalyst-Dev for development issues. The first list is a general support and discussion list, while the second is for patches and discussion of features.

To search the mailing lists, you have a few choices:

* A google search on site: (to search catalyst and catalyst-dev)
* (Catalyst list only)
* (Again Catalyst list only).

The Catalyst mailing list is active, and a good place to generate discussion for material where there might be a bit of complexity, or where you don't need an immediate response. If you submit patches, please submit them to Catalyst-dev rather than the main users mailing list. These lists are fairly high traffic (-dev less so), so if you do submit any patches, chase them up. At the least, you should get a notice that the patch was applied (and hopefully the revision number they were applied as), or some reasons why your patch was rejected.

If you do submit a patch and you don't hear anything, the best place to go to follow up is to irc.


Catalyst has two channels, and is associated with a number of subsidiary channels, all on the irc network . Reflecting the mailing list there is the channel #catalyst for general questions and discussion about Catalyst, or #catalyst-dev for development related questions. In fact most of this advent calendar was coordinated through the #catalyst-dev irc channel. A few other channels of note on this network are #dbix-class for discussion of DBIx::Class, #tt for Template Toolkit related discussion, and #reaction for discussion of the Reaction Component User Interface layer currently being built on top of Catalyst. There is also #perl which is not a help channel and should be handled with caution. For general perl questions go to #perl on instead.

IRC is an extremely valuable resource. Most of the activity on the #catalyst channels happens either late at night (UTC) or early in the working day (same time zone), or around tea time (early evening). /msg purl clock will tell you what time it is where. Because IRC has all the advantages of immediate feedback (like in a conversation) but none of the visual or audio feedback you get in a face-to-face or telephone interaction the capability to be misunderstood is high. This means that you have to take extra care to express yourself clearly and to listen to what other people are trying to tell you. It also means that you should be prepared to be misunderstood and not to take things too personally.

You can also report bugs to Not all authors use this service, although they should, so if you don't get a response fairly quickly, try the author's email in the module. If you have a real problem that you need to resolve and a totally unresponsive author, email to ask about what to do.

What you can contribute.

Patches for bug fixes, or test cases to demonstrate bugs are popular. A test case that requires an example application should be minimal. That is, no extra plugins, use $c->res->body for output where practical and so on.

Documenting how to use features is also important. Where it is possible to provide a simple proof of concept reference implementation for a tutorial this is particularly encouraged. These reference implementations exist for all of the Catalyst::Tutorial applications, the Cheer application from day 1 of this year's advent calendar, the Chained example from day 10, CatTube from day 8 and Geocat from yesterday. Look in to see a wide variety of examples. In fact, the source for the advent calendar application is there under CatalystAdvent.

In some way newbies write the best documentation, so we always ask people new to Catalyst to keep notes, in case they have the time to convert them into useful documentation early in the game.


There are a large number of plugins in the Catalyst::Plugin namespace on CPAN. There are also a few modules in the Catalyst::Controller name space, as well ast the Catalyst::Model, Catalyst::View and Catalyst::Engine name spaces. If you want to write your own Catalyst extensions for CPAN please check via the mailing list and irc (yes, preferably both) if possible, to sanity check your approach and make a general request for comments.


At the moment the easiest scaffolding for Catalyst to get up and running with is Catalyst::Example::InstantCRUD. It uses DBIx::Class and HTML::Widget to provide a rapid database scaffolding module. The HTML::Widget entry (day 19) shows some techniques you can use to extend this. However, remember that while scaffolding can provide you with an attractive looking kick-start to a project (depending on its complexity), working around the assumptions of the scaffolding later on may cost you more time than creating your application by hand in the first place would have taken. Scaffolding does have its uses, just less often than people would like to think. Having said that, Catalyst::Example::InstantCRUD is a very good example of a programmer-centric scaffolding abstraction, extremely useful and easy to extend.


The 2006 advent calendar was a community effort with 13 authors on 4 continents. Documentation is usually a weak point in distributed in-kind funded open source projects like Catalyst. Being able to produce 23 high quality, practical pieces of documentation in just under a month is a testament to the strength of the Catalyst community. Thanks to all the authors, and all the readers.

That's it for this year. Have a happy holiday season, and we'll see you after the break!


Kieren Diment <>