Writing a web application is usually a repetitive process. For every page, you create a new script. This script performs essentially the same tasks as the other scripts in the application such as connecting to a database, getting some input from the user, and producing a web page as the result. This style of application design results in a structure, as shown in the following screenshot:
It may be useful to note that this concerns traditional non-framework designs, as there are more web frameworks for Perl.
Building an application with this sort of design is certainly not a difficult process, but the constant repetition can be prone to error. If you decide to change your database, you will have to update the database connection string in each file. If you happen to forget one obscure file, you might not be aware until your users start sending you angry e-mails.
Of course, this problem is not limited to the database connection strings. As the next diagram shows, repeated elements are there everywhere. As each page generates its own HTML, a request from your web designer to update the layout of a page will involve having to dig through your Perl source code (potentially breaking database queries or other logic), just to change some HTML. In addition, whenever you make a change that affects your entire site or application, you'll have to make the change a number of times—once for each page. Similarly, fixing one bug will entail copying the fix to every other place. This is inconvenient, a waste of time, and just plain boring.
Catalyst is an open source Perl-based Model-View-Controller (MVC) framework that aims to solve this problem by reorganizing your web application.
Rather
than making each location that a user may visit as an individual file, we make each location an action inside a Controller class. Catalyst sits in front of each of these Controllers, and when it receives a request, it dispatches the request to the proper action. When an action is called by the dispatcher, it's in a preconfigured environment—all configuration options have been read from a configuration file at the application start, all databases are connected, all parameters from the request have been parsed, and so on. All your action has to do is implement the logic associated with the request; there is no setup that you have to manually perform, as illustrated in the following diagram:
Although this dispatch mechanism is already an improvement over the traditional process, Catalyst doesn't stop here. Your actions can call on the help of Models and Views as well.
In fact, for more complex problem domains that have a small and flexible Controller handling the actual business logic via models usually gives the most maintainable results.
A Model is a source of data. Most applications use a single relational database such as MySQL or PostgreSQL as their Model, but Catalyst does not require that—you can use anything from files on a disk, to an e-mail server, or remote RSS feeds; also you can have as many Models as your application needs.
Each Model knows how to configure itself at startup (for example, connect to the database server), so you'll never have to worry about that. If you need to use a different database, you can change the connection information in one file, restart your application, and the change will take effect everywhere, automatically. The repetition that a traditional application would require is simply non-existent in Catalyst.
Lastly, a View is another component that your action may use. Only a very limited subset of applications will not need at least one View component.
A View is a way to turn the raw data that your action generates into something more useful to your application's users. Typically, applications have a View that converts the data into an HTML page via a templating system, such as the Template Toolkit, Mason, or ClearSilver.
The View is generally responsible for all matters of representing the response. This also includes serializations such as JSON, or RSS, and Atom feeds.
Templating systems abstract your HTML or XML away from your Perl code, so the web designer can edit it without knowing anything about Perl or the underlying design of your application.
You don't have to completely understand what MVC is right now—we'll start learning the details in the next chapter. For now, think about all the code you've cut and pasted between files in your application and how Catalyst will eliminate that forever.
MVC isn't all that Catalyst provides. At the time of writing, there were over 190 freely available plugins that added new features to Catalyst. Existing plugins offer functionality such as configuration file parsers, specialized logging tools, e-mail interfaces, caching, user authentication and authorization, cryptography, internationalization and localization, browser detection, and even virus scanning. Most of these plugins drop right into your application and instantly provide you with the advertised functionality. This saves you from having to reinvent the wheel for common (and uncommon) tasks.
In addition to plugins, pre-made Models, Controllers, and Views (collectively called components) are also available. As Catalyst is fully object oriented, your application-specific components can simply "subclass" these off-the-shelf components and customize the functionality to whatever degree is necessary.
As new versions of Catalyst are using a powerful system for object orientation called Moose , many extensions to components are behaviors that can be composed in, allowing even more flexibility.
Finally, if there's no pre-built component available, there's the possibility that a generic Perl module from the Comprehensive Perl Archive Network (CPAN), which is available at http://search.cpan.org/, can help you—there are over 10,000 modules currently available!
Another advantage of Catalyst's MVC design is that the components need not be specific to one application. If you're developing a number of related applications, you can share components between them with minimal (or no) modification, as the components are just Perl objects that need not know anything specific about your application. Of course, if you need a component that's specific to your application, that's no problem for Catalyst.
As Catalyst handles all the details of loading your components and handling requests, you aren't tied to any details of this process. This means that you can deploy your application with any web server (Apache and lighttpd are widely used) under whatever configuration best suits your environment. If you're using mod_perl with Apache 1.3, that's no problem for Catalyst. If you're using lighttpd as a proxy to several backend FastCGI servers, Catalyst will work great. Catalyst even comes with a built-in HTTP server, so you can develop applications without having to install and configure a web server.
With Catalyst, like Perl itself, There Is More Than One Way To Do It (TIMTOWTDI), and Catalyst will bend to fit your environment so you can use what you're already familiar with.
Finally, Catalyst is designed to be reliable. The runtime package comes with over 2,600 unit tests that automatically check the reliability of Catalyst when you install it. In the unlikely event that there's something wrong with your Perl environment, Catalyst won't get installed until it's fixed. There's always the possibility of a bug in Catalyst, but nothing major has come up because the core developer team tries to keep Catalyst as small as possible. Everything that's non-essential is kept in plugins or in reusable base components.
This reliability isn't just for the Catalyst developers though. When you create your application (or components within it), unit tests are automatically generated. These tests serve to make sure that your application is at least minimally functional. If you choose to, you can easily add your own automatic tests that can test every part of your application. Rather than manually going through your site when you make a major (or minor) change, you can have the computer double-check everything while you get a cup of coffee. Testing is examined in detail in Chapter 8.
Now that you're convinced that you want to try Catalyst, you just have to install it. As Catalyst is Perl-based, you'll need to have a working version of Perl. Most Linux and BSD distributions come with a suitable Perl in the default install, as do many commercial Unix variants (Mac OS X is no exception). Microsoft Windows doesn't ship with Perl, but you can get a Perl distribution for free from ActiveState, Strawberry Perl, or Cygwin. Regardless of your operating system, you'll need Perl version 5.8.1 or higher (5.8.8, which is the latest at the time of writing, is the version used in this book).
Note
Version 5.10.x is already out, but as 5.8 is more widely used, the examples should stay that way. Ubuntu, for example, already ships 5.10 for a while.
The easiest way to install Catalyst is via your operating system's package manager. This mostly applies to Linux and the BSDs and the syntax is specific to your distribution. On Debian-based versions of GNU/Linux, the command is:
$ apt-get install libcatalyst-perl
On FreeBSD or OpenBSD, you can build the Catalyst port by running the following commands as root:
$ cd /usr/ports/www/p5-Catalyst-Runtime $ make install
If you're using ActiveState on Windows, ActiveState has a PPM (Perl Package Manager) package for Catalyst. You can find the PPM at http://cpan.uwinnipeg.ca/dist/ Catalyst-Runtime.
Finally, be sure to check your operating system's manual for specific instructions on installing packages. The latest details are available from the Catalyst installation guide at http://search.cpan.org/perldoc?Catalyst::Manual::Installation.
If
your operating system doesn't provide packages, installing Catalyst directly from the CPAN is a simple process. Perl ships with a utility called cpan that handles the installation process for you. Simply run the following from the command line:
$ cpan Catalyst::Runtime Catalyst::Devel
and Catalyst (and all of its dependencies) will be downloaded, integrity-checked, and installed.
The disadvantage of this approach is that you'll need a C compiler gcc, make, and related development utilities. Most Linux distributions have these available, but they aren't a part of the default install. Mac OS X offers gcc and make as part of its developer tools package, which you'll need to install if you choose to use cpan.
Unfortunately, the cpan script is notorious for asking difficult questions the first time that you run it (in order to build a configuration suitable for your system). If you want to avoid these questions and just get Catalyst installed, try the cat-install script at http://www.shadowcat.co.uk/static/cat-install. You can download that file, run it with Perl, and Catalyst should be installed when it's finished running.
If
cpan is just not working for you and you feel lost, the Catalyst community would love to help you out. The best place for questions is the #catalyst IRC channel at irc.perl.org. Users, developers, and other helpful people monitor this channel and are happy to answer Catalyst-related questions.
For longer questions, e-mail is probably a better means of communication. Catalyst has an English-language users list that you can sign up for at http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst.
As Catalyst becomes more popular, new lists are being created for other languages. Catalyst-de was recently created for German-speaking users, and there's interest in creating a Japanese-language mailing list. Many readers of the English list speak other languages, so if you're having trouble with English, say so, and someone can likely assist you in your native language. Catalyst-de still exists but does not really have any traffic anymore. Most of the community and (therefore) the knowledge are now found on the English mailing list.
Finally, the main project website, http://www.catalystframework.org/, provides links to useful community tools including the Catalyst wiki, Planet Catalyst (a collection of Catalyst-related blog postings), and the Catalyst Advent Calendar (a mini cookbook published every December).
As always, before posting to the mailing list or asking on IRC, do a quick Google search to see if you're experiencing a common problem.
Many web applications are implemented in a way that makes developing them painful and repetitive. Catalyst, an MVC framework for Perl, lets you design and implement a web application in a natural, maintainable, and testable manner. Everything that your web application needs to do is written only once. You connect to the database in one place, have configuration in one place, and so on. Then, you just write actions for each URL that your application needs, without worrying about the database connections or HTML to produce. Catalyst will handle the details for you. So, you don't need to worry about writing your applications. Thanks to Catalyst's plugin system, it can do more than just dispatch requests—it can manage sessions and users for you, as well as handle many other common tasks. Catalyst is designed to be reliable. There are hundreds of production applications and thousands of users. The code is well tested and new releases almost always maintain compatibility with applications written for older versions. You don't have to worry about Catalyst breaking your application and slowing down your development. It just works!
Most importantly, Catalyst (and Perl) has a thriving community. You can ask a question on the IRC channel and get a response at almost any time of the day. There are also resources on the web for learning more, blogs from developers and users, recipes on the advent calendar, and a wealth of questions answered on the mailing list.
Although this book does a fairly good job of teaching you how to use Catalyst, to truly be able to continually improve and learn to use Catalyst better, you have to learn from the roots. It is important to realize that Catalyst is just a dispatcher that calls the right ORM, Controller, and View. Each of these is merely Perl modules that are well written. So, to understand the flexibility of Catalyst and to leverage its power, you must understand the various options you have in selecting the Model, View, and Controller methods. In this book, we have outlined a few of the commonly used modules. However, it will be beyond the scope of this book to cover every feature for any of the thought modules. It is merely not possible as these components are continuously being improved. Hence, I recommend that you identify the key Perl module/package being thought/used in each chapter and make the effort to learn it independently outside of Catalyst! For example, TT, DBIx::Class, and FormBuider work with any Perl application. It is important that you understand them that way. Catalyst merely makes your life easier by connecting them for you! So, if I were to have a query on models, I would search for documentation on DBIx::Class mostly on cpan instead of searching for documents on Catalyst. Template Toolkit has a dedicated site with a guide that takes no longer than 15 minutes to get started with. So does FormBuilder. If there is one thing that can make a difference to you from this book, it is this concept that each component that you use in Catalyst has to be learnt and mastered individually outside Catalyst. Even if Catalyst allows you to create an orchestra, you still have to learn the individual instruments—keyboard, violin, and guitar—independently outside the orchestra context.