1Catalyst::Manual::AboutU(s3e)r Contributed Perl DocumentaCtaitoanlyst::Manual::About(3)
2
3
4

NAME

6       Catalyst::Manual::About - The philosophy of Catalyst
7

DESCRIPTION

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
15   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
24       •   Interact with a web server
25
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
31           application to work with the new one.
32
33       •   Do something based on a URI
34
35           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
49       •   Interact with a data store
50
51           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
55       •   Handle forms
56
57           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
62       •   Display results
63
64           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
71       •   Manage users
72
73           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
83       •   Develop the application itself
84
85           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
90       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
96       •   Interact with a web server?
97
98           Catalyst lets you use a number of different ones, and even comes
99           with a built-in server for testing or local deployment.
100
101       •   Do something based on a URI?
102
103           Catalyst has extremely flexible systems for figuring out what to do
104           based on a URI.
105
106       •   Interact with a data store?
107
108           Catalyst has many plugins for different databases and database
109           frameworks, and for other non-database storage systems.
110
111       •   Handle forms?
112
113           Catalyst has plugins available for several form creation and
114           validation systems that make it easy for the programmer to manage.
115
116       •   Display results?
117
118           Catalyst has plugins available for a number of template modules and
119           other output packages.
120
121       •   Manage users?
122
123           Catalyst has plugins that handle sessions, authentication, and
124           authorization, in any way you need.
125
126       •   Developing the application?
127
128           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
133       What isn't Catalyst?
134
135       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
140       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
147       Catalyst is not designed for end users, but for working programmers.
148
149   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
154           print "Content-type: text/html\n\n<center><h1>Hello
155           World!</h1></center>";
156
157       for example, or
158
159           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
166       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
176       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
190   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
200       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
211       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
216       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
223       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
228       A simple example
229
230       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
239       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
255       How does this help you?
256
257       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
265       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
276       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
282       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
293       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

SEE ALSO

302       Catalyst, Catalyst::Manual::Intro
303

AUTHORS

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.
310
311
312
313perl v5.36.0                      2023-01-20        Catalyst::Manual::About(3)
Impressum