Catalyst Fringe Benefits

Catalyst does a great job leveraging some useful modules from CPAN. Since Catalyst already requires them, and they are already loaded, you can use them in your app with no additional overhead.

Sure, TMTOWTDI, but why reinvent the wheel? Getting the most out of CPAN is always recommended.

(nothingmuch: not that you should sensibly pass on using a module just because Catalyst doesn't. Especially if Catalyst uses something that *isn't* to your liking but there is an alternative that you prefer! Ease of maintenance first, load time optimizations later!)

Some Examples

The View Module - You have a full templating module, so use it within your code to format things such as: emails, files, xml output, etc. It's not limited just to creating HTML output.

CGI / HTTP Methods: HTTP::Body, HTTP::Response, HTTP::Request, CGI::Cookie (part of CGI.pm), URI, etc. There's no need to parse URLs or HTML (nothingmuch: HTML has nothing to do with HTTP, and you probably don't need to parse HTTP within an abstract-ish controller) with custom regexes.

Data::Dumper - it's already used. Some people avoid loading this in production code due to the overhead. But, it's used to format Catalyst error messages, so use it where you need to. There's even a $c->log->_dump() shortcut. (Though the underscore indicates a private method subject to change in future releases.)

*UPDATE* Catalyst is no longer using Data::Dumper, so if you use it, you have to make it a dependency of your app. Catalyst is now using Data::Dump instead. Try it out, it generates really nice output. The reason for the _ in the _dump method is so subclasses are not required to inherit this method, since it isn't supported by various logging apis. it's not planned to be deprecated or changed.

Class::Accessor::Fast - Catalyst subclasses this one, so it's not even necessary to 'use' if you subclass Catalyst::Base. Just add __PACKAGE__->mkaccessors(qw(foo bar)); and you get an accessor for class variables - $self->foo(5); $self->bar('Hello'); Be warned: Class::DBI overrides the Accessor methods, so do not use in your model classes if you use Class::DBI (or DBIx::Class::CDBICompat).

HTTP::Status - Sometimes code can be easier to read and grok if you return RC_MOVED_PERMANENTLY rather than just 301. There's also useful is_success, is_error, and is_redirect functions that might be of use in your 'sub end'

Path::Class - Provides file() and dir() methods for treating files and paths as objects in a cross-platform way. No need to hardcode slashes in your filenames. Integrates nicely with IO::File - $file->open(); $file->stat() , and File::Path - $dir->mkpath() . This is one of my personal new favorite modules. Catalyst itself could also benefit from using it more consistently in place of the alternatives. It packages the functionality of the following 3 modules:

  • IO::File - OO module for working with files.
  • File::Path - mkpath and rmtree for working with directories.
  • File::Spec - Building paths in a cross-platform manner.
  • File::Copy - Provides copy and move.

Time::HiRes - gettimeofday and short sleeps.

List::Util - OK, this isn't currently 'used' in Catalyst, but it's packaged with Scalar::Util which is used (for weaken). Provides useful array functions like: min, max, sum, first... (nothingmuch: be careful! the reason Catalyst doesn't use List::Util is that it has a history of leaks, a very bad thing in a persistent environment)

Plugins

Of course, this is just Catalyst Core. Each Plugin typically provides a nice interface (decorator / facade) to an outside module. Explore the docs for these modules directly to see what additional things you can do with it.