1Catalyst::Manual::AboutU(s3e)r Contributed Perl DocumentaCtaitoanlyst::Manual::About(3)
2
6 Catalyst::Manual::About - The philosophy of Catalyst
7
9 This document is a basic introduction to the why of Catalyst. It does
10 not teach you how to write Catalyst applications; for an introduction
11 to that please see Catalyst::Manual::Intro. Rather, it explains the
12 basics of what Catalyst is typically used for, and why you might want
13 to use Catalyst to build your applications.
14 What is Catalyst? The short summary
16 Catalyst is a web application framework. This means that you use it to
18 help build applications that run on the web, or that run using proto‐
19 cols used for the web. Catalyst is designed to make it easy to manage
20 the various tasks you need to do to run an application on the web,
21 either by doing them itself, or by letting you "plug in" existing Perl
22 modules that do what you need. There are a number of things you typi‐
23 cally do with a web application. For example:
24 * Interact with a web server
26 If you're on the web, you're relying on a web server, a program
27 that sends files over the web. There are a number of these, and
28 your application has to do the right thing to make sure that your
29 program works with the web server you're using. If you change your
30 web server, you don't want to have to rewrite your entire applica‐
31 tion to work with the new one.
32 * Do something based on a URI
34 It's typical for web applications to use URIs as a main way for
35 users to interact with the rest of the application; various ele‐
36 ments of the URI will indicate what the application needs to do.
37 Thus, "http://www.mysite.com/add_record.cgi?name=John&title=Presi‐
38 dent" will add a person named "John" whose title is "President" to
39 your database, and "http://www.mysite.com/catalog/display/23" will
40 go to a "display" of item 23 in your catalog, and
41 "http://www.mysite.com/order_status/7582" will display the status
42 of order 7582, and "http://www.mysite.com/add_comment/?page=8" will
43 display a form to add a comment to page 8. Your application needs
44 to have a regular way of processing these URIs so it knows what to
45 do when such a request comes in.
46 * Interact with a data store
48 You probably use a database to keep track of your information. Your
49 application needs to interact with your database, so you can cre‐
50 ate, edit, and retrieve your data.
51 * Handle forms
53 When a user submits a form, you receive it, process it to make sure
54 it's been filled in properly, and then do something based on the
55 result--submit an order, update a record, send e-mail, or return to
56 the form if there's an error.
57 * Display results
59 If you have an application running on the web, people need to see
60 things. You usually want your application displayed on a web
61 browser, in which case you will probably be using a template system
62 to help generate HTML code. But you might need other kinds of dis‐
63 play, such as PDF files, or other forms of output, such as RSS
64 feeds or e-mail.
65 * Manage users
67 You might need the concept of a "user", someone who's allowed to
68 use your system, and is allowed to do certain things only. Perhaps
69 normal users can only view or modify their own information; admin‐
70 istrative users can view or modify anything; normal users can only
71 order items for their own account; normal users can view things but
72 not modify them; order-processing users can send records to a dif‐
73 ferent part of the system; and so forth. You need a way of ensuring
74 that people are who they say they are, and that people only do the
75 things they're allowed to do.
76 * Develop the application itself
78 When you're writing or modifying the application, you want to have
79 access to detailed logs of what it is doing. You want to be able to
80 write tests to ensure that it does what it's supposed to, and that
81 new changes don't break the existing code.
82 Catalyst makes it easy to do all of these tasks, and many more. It is
84 extremely flexible in terms of what it allows you to do, and very fast.
85 It has a very large number of "plugins" that interact with existing
86 Perl modules so that you can easily use them from within your applica‐
87 tion.
88 * Interact with a web server?
90 Catalyst lets you use a number of different ones, and even comes
91 with a built-in server for testing or local deployment.
92 * Do something based on a URI?
94 Catalyst has extremely flexible systems for figuring out what to do
95 based on a URI.
96 * Interact with a data store?
98 Catalyst has many plugins for different databases and database
99 frameworks, and for other non-database storage systems.
100 * Handle forms?
102 Catalyst has plugins available for several form creation and vali‐
103 dation systems that make it easy for the programmer to manage.
104 * Display results?
106 Catalyst has plugins available for a number of template modules and
107 other output packages.
108 * Manage users?
110 Catalyst has plugins that handle sessions, authentication, and
111 authorization, in any way you need.
112 * Developing the application?
114 Catalyst has detailed logging built-in, which you can configure as
115 necessary, and supports the easy creation of new tests--some of
116 which are automatically created when you begin writing a new appli‐
117 cation.
118 What isn't Catalyst?
120 Catalyst is not an out-of-the-box solution that allows you to set up a
122 complete working e-commerce application in ten minutes. (There are,
123 however, several systems built on top of Catalyst that can get you very
124 close to a working app.)
125 Catalyst is designed for flexibility and power; to an extent, this
127 comes at the expense of simplicity. Programmers have many options for
128 almost everything they need to do, which means that any given need can
129 be done in many ways, and finding the one that's right for you, and
130 learning the right way to do it, can take time. TIMTOWDI works both
131 ways.
132 Catalyst is not designed for end users, but for working programmers.
134 Web programming: The Olden Days
136 Perl has long been favored for web applications. There are a wide vari‐
138 ety of ways to use Perl on the web, and things have changed over time.
139 It's possible to handle everything with very raw Perl code:
140 print "Content-type: text/html\n\n<center><h1>Hello
142 World!</h1></center>";
143 for example, or
145 my @query_elements = split(/&/, $ENV{'QUERY_STRING'});
147 foreach my $element (@query_elements) {
148 my ($name, $value) = split(/=/, $element);
149 # do something with your parameters, or kill yourself
150 # in frustration for having to program like this
151 }
152 Much better than this is to use Lincoln Stein's great CGI module, which
154 smoothly handles a wide variety of common tasks--parameter parsing,
155 generating form elements from Perl data structures, printing http head‐
156 ers, escaping text, and very many more, all with your choice of func‐
157 tional or object-oriented style. While CGI was revolutionary and is
158 still widely used, it has various drawbacks that make it unsuitable for
159 larger applications: it is slow; your code with it generally combines
160 application logic and display code; and it makes it very difficult to
161 handle larger applications with complicated control flow.
162 A variety of frameworks followed, of which the most widely used is
164 probably CGI::Application, which encourages the development of modular
165 code, with easy-to-understand control-flow handling, the use of plugins
166 and templating systems, and the like. Other systems include AxKit,
167 which is designed for use with XML running under mod_perl; May‐
168 pole--upon which Catalyst was originally based--designed for the easy
169 development of powerful web databases; Jifty, which does a great deal
170 of automation in helping to set up web sites with many complex fea‐
171 tures; and Ruby on Rails (see <http://www.rubyonrails.org>), written of
172 course in Ruby and among the most popular web development systems. Is
173 it not the purpose of this document to criticize or even briefly evalu‐
174 ate these other frameworks; they may be useful for you and if so we
175 encourage you to give them a try.
176 The MVC pattern
178 MVC, or Model-View-Controller, is a model currently favored for web
180 applications. This design pattern is originally from the Smalltalk pro‐
181 gramming language. The basic idea is that the three main areas of an
182 application--handling application flow (Controller), processing infor‐
183 mation (Model), and outputting the results (View)--are kept separate,
184 so that it is possible to change or replace any one without affecting
185 the others, and so that if you're interested in one particular aspect,
186 you know where to find it.
187 Discussions of MVC often degenerate into nitpicky arguments about the
189 history of the pattern, and exactly what "usually" or "should" go into
190 the Controller or the Model. We have no interest in joining such a
191 debate. In any case, Catalyst does not enforce any particular setup;
192 you are free to put any sort of code in any part of your application,
193 and this discussion, along with others elsewhere in the Catalyst docu‐
194 mentation, are only suggestions based on what we think works well. In
195 most Catalyst applications, each branch of MVC will be made of up of
196 several Perl modules that can handle different needs in your applica‐
197 tion.
198 The purpose of the Model is to access and modify data. Typically the
200 Model will interact with a relational database, but it's also common to
201 use other data sources, such as the Xapian search engine or an LDAP
202 server.
203 The purpose of the View is to present data to the user. Typical Views
205 use a templating module to generate HTML code, using Template Toolkit,
206 Mason, HTML::Template, or the like, but it's also possible to generate
207 PDF output, send e-mail, etc., from a View. In Catalyst applications
208 the View is usually a small module, just gluing some other module into
209 Catalyst; the display logic is written within the template itself.
210 The Controller is Catalyst itself. When a request is made to Catalyst,
212 it will be received by one of your Controller modules; this module will
213 figure out what the user is trying to do, gather the necessary data
214 from a Model, and send it to a View for display.
215 A simple example
217 The general idea is that you should be able to change things around
219 without affecting the rest of your application. Let's look at a very
220 simple example (keeping in mind that there are many ways of doing this,
221 and what we're discussing is one possible way, not the only way). Sup‐
222 pose you have a record to display. It doesn't matter if it's a catalog
223 entry, a library book, a music CD, a personnel record, or anything
224 else, but let's pretend it's a catalog entry. A user is given a URL
225 such as "http://www.mysite.com/catalog/display/2782". Now what?
226 First, Catalyst figures out that you're using the "catalog" Controller
228 (how Catalyst figures this out is entirely up to you; URL dispatching
229 is extremely flexible in Catalyst). Then Catalyst determines that you
230 want to use a "display" method in your "catalog" Controller. (There
231 could be other "display" methods in other Controllers, too.) Somewhere
232 in this process, it's possible that you'll have authentication and
233 authorization routines to make sure that the user is registered and is
234 allowed to display a record. The Controller's "display" method will
235 then extract "2782" as the record you want to retrieve, and make a
236 request to a Model for that record. The Controller will then look at
237 what the Model returns: if there's no record, the Controller will ask
238 the View to display an error message, otherwise it will hand the View
239 the record and ask the View to display it. In either case, the View
240 will then generate an HTML page, which Catalyst will send to the user's
241 browser, using whatever web server you've configured.
242 How does this help you?
244 In many ways. Suppose you have a small catalog now, and you're using a
246 lightweight database such as SQLite, or maybe just a text file. But
247 eventually your site grows, and you need to upgrade to something more
248 powerful--MySQL or Postgres, or even Oracle or DB2. If your Model is
249 separate, you only have to change one thing, the Model; your Controller
250 can expect that if it issues a query to the Model, it will get the
251 right kind of result back.
252 What about the View? The idea is that your template is concerned almost
254 entirely with display, so that you can hand it off to a designer who
255 doesn't have to worry about how to write code. If you get all the data
256 in the Controller and then pass it to the View, the template isn't
257 responsible for any kind of data processing. And if you want to change
258 your output, it's simple: just write a new View. If your Controller is
259 already getting the data you need, you can pass it in the same way, and
260 whether you display the results to a web browser, generate a PDF, or
261 e-mail the results back to the user, the Controller hardly changes at
262 all--it's up to the View.
263 And throughout the whole process, most of the tools you need are either
265 part of Catalyst (the parameter-processing routines that extract "2782"
266 from the URL, for example) or are easily plugged into it (the authenti‐
267 cation routines, or the plugins for using Template Toolkit as your
268 View).
269 Now, Catalyst doesn't enforce very much at all. Template Toolkit is a
271 very powerful templating system, and you can connect to a database,
272 issue queries, and act on them from within a TT-based View, if you
273 want. You can handle paging (i.e. retrieving only a portion of the
274 total records possible) in your Controller or your Model. In the above
275 example, your Controller looked at the query result, determining
276 whether to ask the View for a no-result error message, or for a result
277 display; but it's perfectly possible to hand your query result directly
278 to the View, and let your template decide what to do. It's up to you;
279 Catalyst doesn't enforce anything.
280 In some cases there might be very good reasons to do things a certain
282 way (issuing database queries from a template defeats the whole purpose
283 of separation-of-concerns, and will drive your designer crazy), while
284 in others it's just a matter of personal preference (perhaps your tem‐
285 plate, rather than your Controller, is the better place to decide what
286 to display if you get an empty result). Catalyst just gives you the
287 tools.
288
290 Jesse Sheidlower, "jester@panix.com"
291
293 Catalyst, Catalyst::Manual::Intro
294
296 This program is free software, you can redistribute it and/or modify it
297 under the same terms as Perl itself.
298perl v5.8.8 2007-02-28 Catalyst::Manual::About(3)