Dual-license your content for inclusion in The Perl 5 Wiki using this HOWTO, or join us for a chat on irc.freenode.net#PerlNet.


From PerlNet

Jump to: navigation, search

The Catalyst web framework is a model-view-controller web development environment written in Perl. Catalyst is cross-platform, and suited to rapid development.


The Model-View-Controller and Catalyst

Catalyst is an example of a model-view-controller framework, which in turn is a more general example of a design pattern. When solving problems with programs, many developers discover their solution is similar to other solutions but for different problems. When this happens often enough, programmers refer to that style of solution as a "pattern". Patterns are identified by their name, like "the Singleton pattern", or "the Factory pattern".

Patterns evolved out of the world of Graphical User Interfaces (GUIs). In writing GUI applications over and over again, programmers began to see a pattern emerge in their solutions. This pattern was called "Model-View-Controller" or MVC. It consists of three interlocking concepts:

  • The Model is how we organise and store our data, such as a database, text file, or spreadsheet.
  • The View is how we display the data to a user, such as an html page, pie chart, pdf, or iCalendar file.
  • The Controller is how we intercept and dispatch requests from the view to the model, or changes in data from the model to the view. This is discussed in more detail below.

An example

Lets say you have an MVC-based application that displays sales performance at your company. This application connects to a database (a model) that contains your sales figures. The application displays a bar chart (the view) of these sales, with each bar in the chart representing one kind of product you sell. It would be desirable for this graph to update automatically when the database receives a new sales order — if your tractor widget sales increase by 5%, then the bar for this sale should also increase in length by 5%.

We could write our program so that loan modification the database knew how to update the screen, but that means that the database needs to know how to perform screen operations. However the proper role of the database is to maintain data and relationships. Using it for screen updates is likely to be both difficult and cumbersome. Instead, the MVC pattern uses a third concept, that of the controller.

The controller sits between the screen display view and the database model. It may ask the database for the latest sales figures on a scheduled basis, or set up a request to be advised every time the database updates the sales figures. When the controller sees a change it can then request the screen to be redrawn with the new data.

With this approach, the screen code need concentrate solely on drawing issues, the database code can concentrate solely on data issues, and the controller can make decisions about how events in the screen or database are to be handled. The result is cleaner, clearer code in each part.

Catalyst applications

Catalyst provides the MVC pattern as a tool for developers who are creating perl applications.

There are numerous Catalyst modules on CPAN, most falling into helper categories of "Views", "Models", or "Plugins". If you have specific needs for your application and there isn't a module for this already, you can always write your own. It would be worth asking on the Catalyst mailing list if anyone else is already trying to solve this problem as you may be able to colloborate or contribute if that's of interest.

For Catalyst web applications, the MVC implementation choices are most commonly:

  • Model: a database, using any of the drivers supported by DBI. A popular approach for object-oriented programming is to use one of the object-relational mapping modules like Class::DBI or DBIx::Class, which let you use databases without writing much (or in some cases, any!) SQL code.
  • View: a module which formats data in HTML format, for example (Template::Toolkit, HTML::Template, HTML::Mason, ..). There are actually two parts to the view: a perl "View" module which handles any manipulation of data, and a simple "template" which takes care of presenting the end result.
  • Controller: the mastermind of the application, which maps request URIs to functions using the catalyst Dispatcher. Controller modules do the busy work of asking a model for data for a request, and then passing it to a view for presentation. With the variety of application requirements, there aren't many generic examples of controllers. To get you started, there are some useful "helper" controllers on CPAN, including Handel (a commerce framework) and Catalyst::Enzyme (for database create/update/... interaction).

So for a practical example, one combination for a web application might be:

Model View Controller
MySQL database Template::Toolkit custom perl code

Now .. suppose you would like an option to download data from existing pages as XML, so you can fetch this from another application. You could do this by adding a new Rest::XML view to your application, and then updating your controller to choose the XML view when a URL includes "format=xml".

The updated application now supports two views, using the same model:

Model View Controller
MySQL database Template::Toolkit


custom perl code

The essential tenet of the MVC design is that you are able to support different views, models, and controllers with minimal duplication of code and effort.

Getting Started

Installing Catalyst

As of January 2006, Catalyst development is moving quickly so it is important to use an up-to-date install. There is a major release approximately every three months, with several incremental versions in between.

The recommended method of installation is Task::Catalyst from the CPAN. This will install Catalyst and a number of useful quality controlled plugins that provide "best practice" methods, including common functionality such as authentication and authorisation.

Note: you may also notice an older package called Bundle::Catalyst .. this is for previous versions of Catalyst, and you do not want to install it.

Catalyst uses Module::Install to generate installation scripts, so it's also recommended you have an updated version of this installed as a first step.

To install from CPAN using the cpan utility:

   cpan Module::Install
   cpan Task::Catalyst

or cpanp (CPAN+):

   cpanp -i Module::Install
   cpanp -i Task::Catalyst

Finding help on catalyst

  • Mailing list: a fairly active mailing list (10-20+ posts a day) with questions, discussions, and patches. Archives are also available via the mailing list homepage.

Caveat Emptor


  • Catalyst provides a lot of choice... it does not tie you into using a specific database for your model or templating system for your view.
  • Catalyst has a frequent release schedule, and many new features and plugins are being released as the project gains momentum and contributors.
  • Many of the ideas in Catalyst are borrowed from other frameworks like Ruby on Rails, but implemented to play to the strengths of Perl.
  • Catalyst lets you leverage the existing modules on CPAN, with a growing number of plugins to cleanly integrate other popular modules.
  • Catalyst apps can easily be deployed in multiple environments without any changes to application code: apache, apache2, Fast CGI.
  • Catalyst includes a standalone HTTP server with a self-restarting feature to detect any module changes when a page is refreshed.


  • Catalyst provides too much choice in some cases, particularly when you're starting out. There are a few projects in the works that should hopefully make it easier to build something that "just works" with a minimum of choices, for example Catalyst::Enzyme.
  • The Catalyst framework is evolving very rapidly, so some plugin modules may be deprecated or incompatible with new releases. The modules supported by the Catalyst core team are upgraded with each release, but as a general guideline it's often best to wait up to a week or two after a major release for things to settle. Deployment of production releases also requires some appropriate planning for version requirements.
  • Catalyst documentation is sometimes sparse, although a very good manual (including a Tutorial) is now part of the CPAN distribution. Some modules require grubbing through code or asking for help to understand how they work. This is getting better, and contributions to documentation are encouraged via the mailing list, the wiki or via IRC. And APress has put out a good book.

Internal Links

External Links

From the Catalyst team

Comparisons to other application

Articles and Reviews


Personal tools