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