An Introduction to Application Development with Catalyst and Perl

Plugins and Application-Wide Settings

Besides pre-built component classes for drop-in functionality, many plugins
are available to modify the behavior and extend the functionality of
Catalyst itself. A few of the most common are the optional authentication,
authorization and session plugins.

These plugins provide a consistent API for handling these tasks with a
variety of available back ends. Like the core request/response object
interfaces, they are available as application-wide features that are
accessed and controlled through methods in the context object, which become
available once these plugins have been loaded.

You can authenticate a user (within an action handling a login form post,
for example) like this:

If this succeeds, the $c->user object is available in subsequent requests
to control and direct application flow based on the authenticated user.
This is accomplished using sessions (usually cookie-based) that are
handled for you automatically. You also have access to
$c->session to
persist any additional per-session data across requests.

The API of this framework is agnostic to the back end, and many
are available. You can handle authentication and user storage via databases
(DBIC), system accounts, PAM and LDAP, to name a few. There also
are multiple ways to handle session data to support different application
needs, such as distributed server deployments and so on. (See the
documentation for Catalyst::Plugin::Authentication,
Catalyst::Plugin::Authorization and Catalyst::Plugin::Session for more
information.)

Plugins and application-wide settings are configured within the main/core
class (lib/KillerApp.pm). Within this file, you can specify global
configuration parameters, load Plugins and even add your own code to
override and extend core functionality.

The top-level "KillerApp" class actually
is the application—it
programmatically loads and integrates the other components and classes
throughout the system. Like any derived class, its behaviors can be
selectively altered from that of its parent class ("Catalyst"). Since it
uses the powerful "Moose" object system, in addition to adding and
replacing methods, you also can take advantage of additional powerful
features like method modifiers and Roles (in fact, Plugins are essentially
Moose Roles applied to this class).

Catalyst was written with customization and extensibility in mind. It's
structured to allow its functions and behaviors to be modified easily in a
fine-grained manner.

For example, you could configure every response to be set with
"no-cache"
across the whole application simply by adding a method modifier like this
to lib/KillerApp.pm:

Catalyst calls methods with meaningful names (such as 'finalize_headers')
throughout the various stages of processing that you are free to hook into
or override.

Deploying Your Application

Like most things in Catalyst, many options are available when you're
ready to deploy your application to a real Web server—Apache/FastCGI is
one of the best choices available. I briefly cover this below.

If you put your application in /var/www, for example, you can deploy with
an Apache virtual host configuration like this:

FastCGI is a proven, language-independent interface for running Web
applications. It is essentially just plain CGI, but it keeps programs running
in the background instead of firing them up for every request. This is the
major limitation of CGI that FastCGI overcomes. FastCGI has been around
for a long time. The use of this efficient protocol is another example of
how Catalyst leverages existing solutions.

FastCGI allows you to specify the number of processes to run (five in the
example above), making your application multithreaded. Incoming requests
are distributed evenly among the processes, which are maintained in a pool.

The alias for <code>/static/</code> above tells Apache to serve
the files directly in
this directory (images, CSS, JavaScript files and so on). This is more efficient
than serving these files through the application, which isn't necessary.

Conclusion

This article is meant to provide only a taste of Catalyst and its
capabilities. As I hope you have seen, Catalyst is a viable platform for
any Web development project. With a flexible design and many available
mature features, you can use Catalyst to build robust applications quickly
and conveniently.

Catalyst is actively developed and is getting better all the time,
including its ever-increasing quality documentation. It also has a very active
user community with top experts available via IRC.

When you're ready to start writing an application, you should be able to
find the information and support you need to hit the ground running. See
the Resources for this article for important links and where to get started.

The alias for /static/ above tells Apache to serve the files directly in this directory (images, CSS, JavaScript files and so on). This is more efficient than serving these files through the application, which isn't necessary.