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.