various tasks you need to do to run an application on the web, either by
doing them itself, or by letting you "plug in" existing Perl modules
that do what you need. There are a number of things you typically do
-with a web application, for example:
+with a web application. For example:
=over 4
If you're on the web, you're relying on a web server, a program that
sends files over the web. There are a number of these, and your
-application has to do the right thing to make sure that your data works
-with the web server you're using. If you change your web server, you
-don't want to have to rewrite your entire application to work with the
-new one.
+application has to do the right thing to make sure that your program
+works with the web server you're using. If you change your web server,
+you don't want to have to rewrite your entire application to work with
+the new one.
=item * Do something based on a URI
=item * Handle forms
-When a user submits a form, you process it, and make sure it's been
-filled in properly, and then then do something based on the
-result--submitting an order, updating a record, sending e-mail, or going
-back to the form if there's an error.
+When a user submits a form, you receive it, process it to make sure it's
+been filled in properly, and then do something based on the
+result--submit an order, update a record, send e-mail, or return to the
+form if there's an error.
=item * Display results
-You have an application running on the web, people need to see
-things. You usually want to display things on a web browser; you will
-probably be using a template system to help generate HTML code; you
-might need other kinds of display, such as PDF files or RSS feeds.
+If you have an application running on the web, people need to see
+things. You usually want your application displayed on a web browser, in
+which case you will probably be using a template system to help generate
+HTML code. But you might need other kinds of display, such as PDF files,
+or other forms of output, such as RSS feeds or e-mail.
=item * Manage users
extremely flexible in terms of what it allows you to do, and very fast.
It has a very large number of "plugins" that interact with existing Perl
modules so that you can easily use them from within your
-application. Interact with a web server? Catalyst lets you use a number
-of different ones, and even comes with a built-in server for testing or
-local deployment. Do something based on a URI? Catalyst has extremely
-flexible systems for figuring out what to do based on a URI. Interact
-with a data store? Catalyst has many plugins for different databases
-and database frameworks, and for other non-database storage
-systems. Handle forms? Catalyst has plugins available for several form
-creation and validation systems that make it easy for the programmer to
-manage. Display results? Catalyst has plugins available for a number of
-template modules and other output packages. Manage users? Catalyst has
-plugins that handle sessions, authentication, and authorization, in any
-way you need. Developing the application? Catalyst has detailed logging
-built-in, which you can configure as necessary, and supports the easy
-creation of new tests--some of which are automatically created when you
-begin writing a new application.
+application.
+
+=item * Interact with a web server?
+
+Catalyst lets you use a number of different ones, and even comes with a
+built-in server for testing or local deployment.
+
+=item * Do something based on a URI?
+
+Catalyst has extremely flexible systems for figuring out what to do
+based on a URI.
+
+=item * Interact with a data store?
+
+Catalyst has many plugins for different databases and database
+frameworks, and for other non-database storage systems.
+
+=item * Handle forms?
+
+Catalyst has plugins available for several form creation and validation
+systems that make it easy for the programmer to manage.
+
+=item * Display results?
+
+Catalyst has plugins available for a number of template modules and
+other output packages.
+
+=item * Manage users?
+
+Catalyst has plugins that handle sessions, authentication, and
+authorization, in any way you need.
+
+=item * Developing the application?
+
+Catalyst has detailed logging built-in, which you can configure as
+necessary, and supports the easy creation of new tests--some of which
+are automatically created when you begin writing a new application.
=head3 What B<isn't> Catalyst?
Catalyst is not an out-of-the-box solution that allows you to set up a
complete working e-commerce application in ten minutes. (There are,
however, several systems built on top of Catalyst that can get you very
-close to a working app.) It is not designed for end users, but for
-working programmers.
+close to a working app.)
+
+Catalyst is not designed for end users, but for working programmers.
=head2 Web programming: The Olden Days
Perl has long been favored for web applications. There are a wide
variety of ways to use Perl on the web, and things have changed over
time. It's possible to handle everything with very raw Perl code:
-C<print "Content-type: text/html\n\n<center><h1>Hello
-World!</h1></center>";> for example, or
+
+ print "Content-type: text/html\n\n<center><h1>Hello
+ World!</h1></center>";
+
+for example, or
my @query_elements = split(/&/, $ENV{'QUERY_STRING'});
foreach my $element (@query_elements) {
http headers, escaping text, and very many more, all with your choice of
functional or object-oriented style. While L<CGI> was revolutionary and
is still widely used, it has various drawbacks that make it unsuitable
-for larger applications: it is slow, your code with it generally
-combines application logic and display code, and it makes it very
+for larger applications: it is slow; your code with it generally
+combines application logic and display code; and it makes it very
difficult to handle larger applications with complicated control flow.
A variety of frameworks followed, of which the most widely used is
L<AxKit>, which is designed for use with XML running under mod_perl, and
L<Maypole>--upon which Catalyst was originally based--designed for the
easy development of powerful web databases. Is it not the purpose of
-this document to criticize or even evaluate these other frameworks; they
-may be useful for you and if so we encourage you to give them a try.
+this document to criticize or even briefly evaluate these other
+frameworks; they may be useful for you and if so we encourage you to
+give them a try.
=head2 The MVC pattern
the Controller or the Model. We have no interest in joining such a
debate. In any case, Catalyst does not enforce any particular setup; you
are free to put any sort of code in any part of your application, and
-this discussion (and others elsewhere in the Catalyst documentation) is
-only a suggestion based on what we think works well. In most Catalyst
-applications, each branch of MVC will be made of up of several Perl
-modules that can handle different needs in your application.
+this discussion, along with others elsewhere in the Catalyst
+documentation, are only suggestions based on what we think works
+well. In most Catalyst applications, each branch of MVC will be made of
+up of several Perl modules that can handle different needs in your
+application.
The purpose of the B<Model> is to access and modify data. Typically
the Model will interact with a relational database, but it's also
common to use other data sources, such as the L<Plucene> search
-engine, an LDAP server, etc.
+engine or an LDAP server.
The purpose of the B<View> is to present data to the user. Typical Views
use a templating module to generate HTML code, using L<Template
Toolkit|Template>, L<Mason|HTML::Mason>, L<HTML::Template>, or the like,
-but it's also possible to generate PDF output, send email, etc., from a
-View. In Catalyst the View is usually a small module, just gluing some
-other module into Catalyst; the display logic is written within the
-template itself.
+but it's also possible to generate PDF output, send e-mail, etc., from a
+View. In Catalyst applications the View is usually a small module, just
+gluing some other module into Catalyst; the display logic is written
+within the template itself.
The Controller is Catalyst itself. When a request is made to Catalyst,
it will be received by one of your Controller modules; this module
First, Catalyst figures out that you're using the "catalog" Controller
(how Catalyst figures this out is entirely up to you; URL dispatching is
-I<extremely> flexible in Catalyst). Then Catalyst sees that you want to
-use a "display" method in your Controller. Somewhere in this process,
-it's possible that you'll have authentication and authorization routines
-to make sure that the user is registered and is allowed to display a
-record. The Controller's display method will then extract "2782" as the
-record you want to retrieve, and make a request to a Model for that
-record. The Controller will then look at what the Model returns: if
-there's no record, the Controller will ask the View to display an error
-message, otherwise it will hand the View the record and ask the View to
-display it. In either case, the View will then generate an HTML page,
-which Catalyst will display to the user's browser, using whatever web
-server you've configured.
+I<extremely> flexible in Catalyst). Then Catalyst determines that you
+want to use a C<display> method in your "catalog" Controller. (There
+could be other C<display> methods in other Controllers, too.) Somewhere
+in this process, it's possible that you'll have authentication and
+authorization routines to make sure that the user is registered and is
+allowed to display a record. The Controller's C<display> method will
+then extract "2782" as the record you want to retrieve, and make a
+request to a Model for that record. The Controller will then look at
+what the Model returns: if there's no record, the Controller will ask
+the View to display an error message, otherwise it will hand the View
+the record and ask the View to display it. In either case, the View will
+then generate an HTML page, which Catalyst will send to the user's
+browser, using whatever web server you've configured.
How does this help you?
In many ways. Suppose you have a small catalog now, and you're using a
-lightweight database such as SQLite, or even a text file. But eventually
-your site grows, and you need to upgrade to something more
+lightweight database such as SQLite, or maybe just a text file. But
+eventually your site grows, and you need to upgrade to something more
powerful--MySQL or Postgres, or even Oracle or DB2. If your Model is
separate, you only have to change one thing, the Model; your Controller
can expect that if it issues a query to the Model, it will get the right
-kind of result back.
+kind of result back.
What about the View? The idea is that your template is concerned almost
entirely with display, so that you can hand it off to a designer who
in the Controller and then pass it to the View, the template isn't
responsible for any kind of data processing. And if you want to change
your output, it's simple: just write a new View. If your Controller is
-already getting the data you need, you pass it in the same way, and
+already getting the data you need, you can pass it in the same way, and
whether you display the results to a web browser, generate a PDF, or
e-mail the results back to the user, the Controller hardly changes at
-all.
+all--it's up to the View.
And throughout the whole process, most of the tools you need are either
part of Catalyst (the parameter-processing routines that extract "2782"
from the URL, for example) or are easily plugged into it (the
-authentication routines, the plugins for using Template Toolkit as your
-View).
+authentication routines, or the plugins for using Template Toolkit as
+your View).
-Now, Catalyst doesn't enforce very much at all. You can connect to a
-database, issue queries, and act on them from within your View, if you
+Now, Catalyst doesn't enforce very much at all. Template Toolkit is a
+very powerful templating system, and you can connect to a database,
+issue queries, and act on them from within a TT-based View, if you
want. You can handle paging (i.e. retrieving only a portion of the total
-records possible) in your Controller or your Model. It's up to you. In
-some cases there might be very good reasons to do things a certain way
-(issuing database queries from a template seems to defeat the whole
-purpose of separation-of-concerns, and will drive your designer crazy),
-while in others it's just a matter of personal preference (perhaps your
-template, rather than your Controller, is the better place to decide
-what to display if you get an empty result). Catalyst just gives you the
-tools.
+records possible) in your Controller or your Model. In the above
+example, your Controller looked at the query result, determining whether
+to ask the View for a no-result error message, or for a result display;
+but it's perfectly possible to hand your query result directly to the
+View, and let your template decide what to do. It's up to you; Catalyst
+doesn't enforce anything.
+
+In some cases there might be very good reasons to do things a certain
+way (issuing database queries from a template defeats the whole purpose
+of separation-of-concerns, and will drive your designer crazy), while in
+others it's just a matter of personal preference (perhaps your template,
+rather than your Controller, is the better place to decide what to
+display if you get an empty result). Catalyst just gives you the tools.
=head1 AUTHOR
projects / catagits/Catalyst-Runtime.git / blobdiff