3 Catalyst::Manual::Tutorial - Getting started with Catalyst
7 This document aims to get you up and running with Catalyst.
11 The first step is to install Catalyst, and the simplest way to do this
12 is to install the Catalyst bundle from CPAN:
14 $ perl -MCPAN -e 'install Task::Catalyst'
16 This will retrieve Catalyst and a number of useful extensions and
17 install them for you. This process might not be totally painless
18 though, and you might want to look at CatInABox
19 L<http://use.perl.org/~jk2addict/journal/28071>, especially if you are
20 on a system that lacks a compiler.
23 =head2 The very basics - Setting up the skeleton application.
25 Catalyst includes a helper script, C<catalyst.pl>, that will set up a
26 skeleton application for you:
31 created "MyApp/script"
33 created "MyApp/script/myapp_create.pl"
35 This creates the directory structure, populated with skeleton
38 =head2 Testing out the skeleton application
40 You can test out your new application by running the server script that
44 $ script/myapp_server.pl
46 [...] [catalyst] [debug] Debug messages enabled
47 [...] [catalyst] [debug] Loaded plugins:
48 .------------------------------------------------------------------------------.
49 | Catalyst::Plugin::Static::Simple |
50 '------------------------------------------------------------------------------'
51 [...] [catalyst] [debug] Loaded dispatcher "Catalyst::Dispatcher"
52 [...] [catalyst] [debug] Loaded engine "Catalyst::Engine::HTTP"
53 [...] [catalyst] [debug] Found home "/home/users/me/MyApp"
54 [...] [catalyst] [debug] Loaded Private actions:
55 .--------------------------------------+---------------------------------------.
57 +--------------------------------------+---------------------------------------+
59 '--------------------------------------+---------------------------------------'
61 [...] [catalyst] [info] MyApp powered by Catalyst 5.5
62 You can connect to your server at http://localhost:3000
64 (Note that each line logged by Catalyst begins with a timestamp, which has
65 been replaced here with "C<...>" so that the text fits onto the lines.)
67 The server is now waiting for you to make requests of it. Try using
68 telnet to manually make a simple GET request of the server (when
69 telnet responds with "Escape character is '^]'.", type "GET / HTTP/1.0"
70 and hit return twice):
72 $ telnet localhost 3000
74 Connected to localhost.
75 Escape character is '^]'.
79 Date: Mon, 07 Nov 2005 14:57:39 GMT
81 Content-Type: text/html; charset=utf-8
86 Connection closed by foreign host.
89 You can see the full welcome message by visting
90 http://localhost:3000/ with your browser.
92 More trace messages will appear in the original terminal window:
94 [...] [catalyst] [debug] **********************************
95 [...] [catalyst] [debug] * Request 1 (0.063/s) [2148]
96 [...] [catalyst] [debug] **********************************
97 [...] [catalyst] [debug] Arguments are ""
98 [...] [catalyst] [debug] "GET" request for "" from localhost
99 [...] [catalyst] [info] Request took 0.046883s (21.330/s)
100 .------------------------------------------------------------------+-----------.
102 +------------------------------------------------------------------+-----------+
103 | /default | 0.000000s |
104 '------------------------------------------------------------------+-----------'
106 The server will continue running until you interrupt it.
108 The application can also be tested from the command line using the generated
109 helper script, C<script/myapp_test.pl>.
111 =head2 Getting started
113 So you picked Catalyst. Good choice. I assume you've installed it as
114 well. For this tutorial you will also need the following modules:
116 L<Catalyst::Plugin::Session>
118 L<Catalyst::Plugin::Session::Store::File>
120 L<Catalyst::Plugin::Session::State::Cookie>
122 L<Catalyst::Plugin::Authentication>
124 L<Catalyst::Plugin::Authentication::Store::Minimal>
126 L<Catalyst::Plugin::Authentication::::Minimal>
128 L<Catalyst::Plugin::Authentication::Credential::Password>
130 L<Catalyst::Plugin::Authorization::Roles>
136 To get started all you need to do is type:
138 B<catalyst.pl tutorial>
141 Poor choice of application name - searching for "tutorial" in the docs
142 also results in discussion of the tutorial process, which is probably
143 not what the reader wants.
147 This should create a directory called F<tutorial> and fill it with the
148 default (standard) Catalyst installation. Change to this directory
149 because we will be running all further commands from inside the
150 F<tutorial> directory.
152 If you now run the built-in mini-server with
153 B<script/tutorial_server.pl>, it will show some standard debug messages
154 in the console screen (more about those in a minute), and then inform
155 you that you can now connect to the test server on port 3000. Point your
156 browser at localhost:3000 to see the built-in catalyst welcome screen.
158 The other important thing catalyst.pl did was create your root
159 controller. This file is a standard perl module like all the other
160 controllers that you might add to your application. It lives in the
161 F<lib/> directory, and will have the same name as you supplied to the
162 command above, in our case it is F<tutorial.pm>. Alongside this file is
163 a directory of the same name, which is the top level namespace for the
164 entire application. Thus every other module we create will be
165 "tutorial::something";
167 The root controller is used to load plugins, to configure the
168 application and its plugins, and for generic private actions. We will
169 explain more about those later.
173 The simplest way to debug your Catalyst application is to run it using
174 the built-in mini-server as described in L<Getting started>.
176 If you want to output any debugging information to the console, then
177 call C<< $c->log->debug() >>, passing it a string to output. For
178 data structures, use Data::Dumper and call C<<
179 $c->log->debug(Dumper($structure)) >>
181 =head2 Model/View/Controller
183 The recommended method for code organization in a Catalyst application
184 is known as the "Model View Controller" design pattern (also referred to
185 "MVC"). The point of the MVC pattern is to divorce the dependencies of
186 parts of the application from each other, and give them standard
187 interfaces. Following this theory of organization should give your code
188 all the benefits of modularity. The main benefits are interchangability
189 of parts and reusable code.
191 Thus you could replace your file data storage with a database or your
192 oracle database with a mysql database and not have to change any of your
193 controlling or view logic. Or you could later decide to output
194 information from your application as RSS instead of HTML just by adding
199 Models deal with the storage of data. For a complex website, you may
200 need multiple varied data sources, each will have it's own model class
201 that provides an abstracted interface to it. In this tutorial we are
202 going to be using a simple database.
206 Views are used to display information to the user. In a web framework,
207 it is generally used to output HTML to the browser. As mentioned
208 previously, views can also be used to output RSS or any other kind of
209 data format. One easy way to do this with Catalyst is to use a
210 templating system such as Template Toolkit. If outputting HTML is all
211 you are going to do, then you will probably only need one view.
215 A controller deals with reacting to user choices, and thus controls what
216 the application does. Since this is a web framework, Catalyst
217 controllers are frequently used to react directly to URLs requested by
218 the user. This tutorial will describe the simplest way of using
219 controllers, where each path or part of a path is assigned its own
220 action (or subroutine). More complex controlling mechanisms will be
221 mentioned briefly, and can be read about in detail in the manual.
226 Now lets write our first bit of application code. First, we would like
227 our application to greet our users. We'll assume for now that our users
228 will be sent to the I<users/greet> URL. To create a controller that
229 serves the I<users> namespace, we run the following command in our
230 F<tutorial> directory:
232 B<script/tutorial_create.pl controller Users>
234 This will create a Users.pm in F<lib/tutorial/Controller>. Open this
235 file in an editor and take a look. You will notice there is some
236 commented out code which we will ignore for now. To make something
237 happen when our URL is visited, we will write a "greet" action which
243 my $name = $c->req->param('name');
244 $c->log->debug("Got name: $name\n");
246 if ($c->req->method eq 'POST') {
248 $c->stash->{message} = 'Please fill in a name!';
251 $c->stash->{message} = "Hello $name!";
254 $c->stash->{template} = 'greet.tt';
257 Whew! So, what does all this do? Lets take it one step at a time.
258 The subroutine declaration gives the action a name. To the right of the
259 name there is an attribute type that looks like this: " : Local". That
260 defines which URIs will translate to this action. "Local", matches
261 exactly one URI: /users/greet. The URI matched by "Local" is composed
262 from the namespace minus the tutorial::controller portion, that is
263 common to all controllers, and the action name itself. Because it is a
264 URI, we use forward slashes instead of double colons. So, in summary,
265 when a user requests http://localhost:3000/users/greet" the "greet"
266 action defined above in the Users controller will be executed.
268 The second line retrieves the parameters Catalyst gives us when it calls
269 our method. The first is the instance of our Users class, and the second
270 is commonly called the context, and named $c. From now on, whenever we
271 are talking about the context object, it will be represented as $c in the code.
273 The context is the magical object containing any information you need from catalyst,
274 or want to send to it, and is passed from action to action. You will see it used
275 frequently in Catalyst applications, and a list of all its methods is available in
278 On the third line we use the ->param method of the context's request object
279 to retrieve one of the query parameters, just like in L<CGI>.
281 On the fourth, we make a debug output of this object on the server console,
282 or the error log if running under CGI or mod_perl.
284 Next, if we have a post request, we check if the name field contains anything
285 (or is "true"), if it isnt, we assign an error message to a "message" field in
286 the stash. The stash is yet another method of the context object, it allows us
287 to pass data on to other methods we call later, most usefully the View modules.
289 If the username did contain a value, then we just set our message to
290 greet the user by name.
292 Finally, we set the special "template" variable in the stash to the name
293 of the template we want our view to use to display this page.
297 Ok, so reacting and checking the users data is all fine, but how do we
298 actually display the page/form in the first place, and our results? As
299 previously mentioned, we'll use Template Toolkit for our viewing. To
300 create out TT based view, just run the following command:
302 B<script/tutorial_create.pl view TToolkit TT>
304 Notice that this time we not only gave it the type of module we wanted
305 to create (a view), and a name, but also a third argument, "TT". This is
306 a Catalyst helper module, which will make a standard template toolkit
307 module for you. And that's all you need to do there.
309 To use the view, the easiest way is to set up a standard "end" action.
310 This a private action which will not be matched to a path like our
311 "greet" action, but instead will be called after all other processing is
312 done. Only one end action will be called, if there is one in a
313 controller, it will be prefered over one in the application module, and
316 Since we're writing a simple application, just add an end action like
317 this to F<tutorial.pm>:
321 $c->forward('tutorial::View::TToolkit') unless $c->res->body();
324 The first line declares the end sub, and marks it as a Private action.
325 (The second and last attribute type we'll be using). The second line
326 collects our standard parameters as shown in the controller's greet action.
328 The third line directs Catalyst to pass processing on to our TToolkit
329 view. The forward method, when just passed a class name, calls process
330 on that classs. The standard TT view's process method renders the
331 template named in the templare variable in the stash, using all the
332 other variables in the stash as values to fill it in.
334 NB: This is such a common way to end you processing that there is a
335 plugin which does it for you: L<Catalyst::Plugin::DefaultEnd>.
337 Template Toolkit also has access to the entire context object via "c",
338 for example, using [% c.config.name %] in our template will output
339 "tutorial", our project name.
341 All that remains is to create a simple template called "greet.tt",
342 containing a form with a text field called "name" like below.
344 <html><head><title> [% c.name %]</head><body>
346 <form action="[%c.req.uri%]" method="post">
347 <input type="text" name="name"/>
348 <input type="submit" value="Submit" name="submit"/>
352 In the example above, we use [%c.req.uri%], since we're posting to ourself.
353 if we post to another action, we commonly use the uri_for method, like this:
355 [% c.uri_for('/users/greet')%]
357 Place this file in the F<root> directory, . By default, templates are
358 searched for here, but we can change that, which brings us to...
362 As previously mentioned, the configuration of modules, plugins and so on
363 is done in the main application file. This is especially true for bits
364 which need to be done before an instance of them is created, for example
367 The TT View looks for its templates in the F<root> directory by default.
368 Since this is also the directory that static files go in, we'd rather
369 have a separate F<templates> directory. To do this, change the config
370 call in F<tutorial.pm> like this:
372 __PACKAGE__->config( name => 'tutorial',
373 'View::TToolkit' => {
374 'INCLUDE_PATH' => __PACKAGE__->path_to('templates')
378 And move the F<greet.tt> file from F<root> to the F<templates> directory
381 Now we can run our application again by killing (ctrl-c) and restarting
382 B<script/tutorial_server.pl>. Try connecting to
383 I<localhost:3000/users/greet> with a browser and see what happens. What
384 happens if you try to visit I<localhost:3000/users> ?
386 =head2 Users and Authenticating
388 One of the many reasons to write dynamic websites instead of just using static
389 HTML, is to allow us to produce different content for different users, as well
390 as just restricting access to pages (which we could do with just Apaches
393 In this tutorial, we will just be using basic authentication, when writing
394 a real application, you'll want to use a database or other secure store to
395 contain your user data.
397 To add authentication, all we need to do is add the
398 L<Catalyst::Plugin::Authentication> module to our main application file. Then
399 we need to pick a storage method (one of the
400 L<Catalyst::Plugin::Authentication::Store> modules), and a method of verifying
401 the users credentials (one of the
402 L<Catalyst::Plugin::Authentication::Credential> modules), so just edit
403 F<tutorial.pm> to look like this:
405 use Catalyst qw/-Debug Static::Simple Authentication
406 Authentication::Store::Minimal
407 Authentication::Credential::Password/;
409 To configure, add some users to the config call, for example:
411 authentication => { 'users' =>
413 { 'password' => 'fred1234',
418 Generally, setting up configuration data for plugins is done based on the
419 type of plugin. Check the documentation of the plugin for exact details. The
420 details of this one are in L<Catalyst::Plugin::Authentication::Store::Minimal>.
422 Since our user data is in the config, we can update it at runtime, and thus
423 add users dynamically. (Of course, to keep them permanently we'll need to
424 export our data to disk and read it back into the config on startup)
426 To allow creation of new users we'll add a create action to our Users
431 my ($username, $passwd1, $passwd2) = map { $c->req->param($_)}
432 ('username', 'password', 'passwordverify');
434 if($username && $passwd1 && $passwd2) {
435 if($c->config->{authentication}{users}{$username}) {
436 $c->stash->{message} = 'Sorry that user already exists';
437 $c->stash->{username} = $username;
439 elsif($passwd1 eq $passwd2) {
440 $c->config->{authentication}->{users}->{$username} =
441 {password => $passwd1};
442 $c->stash->{message} = 'User created!';
445 $c->stash->{username} = $username;
446 $c->stash->{message} = 'Passwords do not match!';
449 $c->stash->{template} = 'usercreate.tt';
452 All this is doing is checking that all the appropriate fields are filled,
453 the password fields contain the same data, and then adding the user to the
454 config hash. All the checks produce a message which can be displayed to
455 the user via the View.
457 The usercreate.tt template looks like this:
459 <html><head><title>[% c.config.name %]</title></head><body>
460 <h1>Create a new user</h1>
461 <p> [% c.stash.message %] </p>
462 <form action="/users/create" method="post">
463 <p>User Name: <input type="text" name="username"/></p>
464 <p>Password: <input type="password" name="password"/></p>
465 <p>Confirm Password: <input type="password" name="passwordverify"/></p>
466 <p><input type="submit" name="submit" value="submit"></p>
470 So our that users can login, we need a login action which we put in the
475 $c->stash->{template} = 'userlogin.tt';
477 $c->stash->{message} = 'Please login.';
480 $c->stash->{message} = "Welcome " . $c->user->id;
485 And the userlogin.tt template:
487 <html><head><title>[% c.config.name %]</title></head><body>
488 <p> [% c.stash.message %] </p>
489 <form name='login' action='/users/login' method='post'>
490 <p>Username: <input type='text' name='user' /></p>
491 <p>Password: <input type='password' name='password' /></p>
492 <p><input type="submit" /></form>
496 Verrrry simple. Since Credential::Password's "login" call extracts the
497 username/password data from the query itself (assuming we use a standard
498 name for our form fields), we don't have to do anything but call it.
500 To keep the user logged in, all we need to do is add the Session modules to
501 our collection, and the Auth modules will automatically use them;
503 use Catalyst qw/-Debug Static::Simple Authentication
504 Authentication::Store::Minimal
505 Authentication::Credential::Password
506 Session Session::Store::File Session::State::Cookie/;
512 As an exercise for the reader, do the following:
514 Change users/greet and greet.tt so that the welcome message greets the
517 Enforce user logging in by adding an auto action in tutorial.pm (see
518 the L<Catalyst> documentation to find out about the auto action).
522 Authentication is about verifying users, Authorisation is about
523 allowing them to do things. Catalyst currently has two Authorisation
524 modules, Roles and ACL. The Roles module allows you to define groups
525 which you can assign your users to, and then allow access to areas of
526 your website to the groups. The ACL module lets you do more fine
527 grained access/restriction by allowing of denying access however you
528 like. (It also supports Roles as done by the roles module.) This
529 example uses Catalyst::Plugin::Authorization::Roles. To use this add
530 "Authorization::Roles" into the "use Catalyst" statement in
533 Adding Roles via the Minimal store we are already using is quite simple,
534 we just add a roles key to each user, defining the names of the roles
537 authentication => { 'users' =>
539 { 'password' => 'fred1234',
545 We need an interface for our admins to administer the roles, i.e. assign
546 the users to groups. To restrict access to certain actions, we just need
547 to call C<< $c->check_user_roles() >> in each action. So we can
548 make a restricted I<localhost:3000/users/groups> page like this:
552 if($c->check_user_roles('admin')) {
553 # Now we can do things only an admin will see
554 if(my $params = $c->req->params) {
555 my $users = $c->config->{authentication}{users};
556 foreach my $u (keys %$params) {
557 $users->{$u}{roles} = $params->{$u} if($users->{$u});
559 $c->stash->{message} = 'Updated user roles!';
562 $c->stash->{users} = $c->config->{authentication};
564 $c->stash->{template} = 'usersgroups.tt';
567 $c->stash->{message} = 'Admins Only!';
568 $c->stash->{template} = 'error.tt';
572 What we are doing here is checking whether the logged in user (used by
573 default in the check_user_roles method), is a member of the admin group.
574 If it is, then we display the usergroups template, and update the users
575 hash as required. Otherwise, we just show the user an error page.
577 For this simple example, the usersgroups.tt and error.tt templates could
580 <html><head><title>[% c.config.name %]</title></head><body>
581 <p>[% c.stash.message %]</p>
582 <p>[% c.stash.users %]</p>
585 And that's all there is to it.
588 So it's not clear what the groups action is doing - and with the
589 current template, nothing happens. Running through the sample code,
590 it's clear what's happening, (which is very little), but the purpose,
591 and how to display data is not clear.
595 So that you can test this out properly without having to go to the
596 trouble of deleting browser cookies manually, we will add a logout
597 action in the Users controller:
601 $c->stash->{message} = "You have successfully logged out";
606 =head2 Data Storage (Modelling)
608 Whether we want our users to be able to contribute to our website, or just
609 create it from changeable data, we need to store the data somewhere. Generally
610 this is done using a database, models can also be other data sources, for
611 example another website, or RSS feeds.
613 If you have or want a database, there are still choices to be made, there are
614 several modules about for accessing databases via OO. The best known are
615 probably L<Class::DBI> and L<DBIx::Class>. Catalyst supports making models
616 using either of these.
618 For a simple example, we will allow our users to store their favourite
619 greeting in our database. Create a table called "greetings" in a database,
620 that contains a "user" field and a "greeting" field. The simplest way to
621 create a model of your database is to use these helper modules, for example
624 B<script/tutorial_create.pl model UserData DBIC dbi:SQLite:/path/to/mydb.db>
626 This will cause the DBIx::Class Loader to inspect your database, and create a
627 module in the Model::UserData namespace for each table in your database.
629 Now we need a form for our users to enter/edit their personal greetings in,
630 we'll make a I<localhost:3000/users/editgreeting> page:
632 sub editgreeting : Local {
634 if($c->req->params->{greeting}) {
635 if(!$c->user_exists) {
636 $c->stash->{message} = "You're not logged in!";
639 my $grtable = $c->model('UserData::Greetings');
640 my $record = $grtable->find_or_create(user => $c->user->id);
641 $record->greeting($c->req->params->{greeting};
643 $c->stash->{message} = 'Greeting updated';
646 $c->stash->{template} = 'usersgreeting.tt';
649 Using C<< $c->user_exists >> from the Authentication plugin, this checks
650 whether the user is logged in already. If they are, if they are, and they have
651 entered a new greeting, we use DBIx::Class' C<find_or_create> to fetch or
652 create a new record in the greetings table for the user. Once we have the
653 record, we change the value of the greeting field, and call C<update> to store
654 the new value in the database.
656 =head2 Engines (Apache and FastCGI)
658 Now that we have the basics together, we can try running our application on a
659 "real" server instead of just using the test server that catalyst comes
660 with. L<Catalyst::Engine> is the module used to implement various types of
661 servers to run it on. The currect popular ones are Apache and FastCGI. To
662 force the use of a particular engine we can use the -Engine flag to Catalyst:
664 use Catalyst qw/-Engine=Apache/;
668 use Catalyst qw/-Engine=FastCGI/;
672 Apache also needs to be configured: we need to tell it to load your
673 application. You can either use Catalyst for your entire website, or
674 subsections. Use the Location directive to choose a path to run your
678 SetHandler perl-script
679 PerlResponseHandler MyApp
682 You will need to install the perl modules of your application into one of
683 perls library directories, as listed by B<perl -V>, so that Apache can find
684 them. Alternatively you can use the C<PerlSwitches> directive to tell Apache
687 PerlSwitches -I/path/to/MyApp/
689 These instructions are for using Apache2 and mod_perl 2.0. If you are using
690 mod_perl 1.3 or 1.99, please refer to either L<Catalyst::Engine::Apache::MP13>
691 or L<Catalyst::Engine::Apache2::MP19> for slightly different ways to do it.
693 If you wish to ensure that Apache pre-loads your application, use the
694 PerlModule directive. This means that there will be less of a delay when your
695 application is accessed.
701 These instructions apply to the use of C<mod_fastcgi> under Apache
702 (either 1 or 2 series).
704 There are 3 ways to attach a program to a URL with C<mod_fastcgi>;
705 we'll examine all of them, and explain how to avoid having the
706 C<myapp_fastcgi.pl> substring in the user-visible URLs.
708 In all of these examples, we assume that the C<DocumentRoot> is
709 C</var>, that our app is called C<MyApp> and is kept in C</usr>, that
710 you want the users to access the app either from the root of the
711 server-uri-space, or from C</theapp>. We also assume that the general
712 FastCGI settings (C<FastCgiIpcDir>, loading the module) are already
713 correct (they don't depend on Catalyst or your application layout).
715 =head4 static application
717 In this setup, you tell C<mod_fastcgi> that a particular I<file> is to
718 be run as a FastCGI handler. Put this somewhere in Apache's
721 FastCgiServer /usr/apps/MyApp/script/myapp_fastcgi.pl
722 Alias / /usr/apps/MyApp/script/myapp_fastcgi.pl/
724 If you want your app under C</theapp>, change the C<Alias> line to:
726 Alias /theapp /usr/apps/MyApp/script/myapp_fastcgi.pl
728 Note the detail of the trailing C</ >: this is a general rule af the
729 C<Alias> directive, both sides must end with C</ >, or both must not;
730 you can't have one with C</ > and the other without, or strange things
733 =head4 dynamic application
735 In this setup, you tell C<mod_fastcgi> that certain files are to be
736 treated as FastCGI handlers, in the same way you have to tell
737 C<mod_cgi>. Put this in the configuration:
739 FastCgiConfig -autoUpdate
741 <Directory /usr/apps/MyApp/script>
744 SetHandles fastcgi-script
748 Alias / /usr/apps/MyApp/script/myapp_fastcgi.pl/
750 Again, if you want your app under C</theapp>, change the C<Alias> line to:
752 Alias /theapp /usr/apps/MyApp/script/myapp_fastcgi.pl
754 =head4 external server
756 In this setup, the application is started separately from Apache, and
757 communicates via a socket with C<mod_fastcgi>. This can be useful if
758 you need to have a particular environment for your application (maybe
759 different between applications), or you want to run them on different
760 machines, or under different users for security reasons.
762 If you want to use a UNIX socket (on the filesystem), put this in
763 Apache's configuration:
765 FastCgiExternalServer /tmp/somewhere -socket /tmp/myapp-socket
766 Alias / /tmp/somewhere/
768 Note that C</tmp> should I<not> exist: it's just a name to connect the
771 Again, if you want your app under C</theapp>, change the C<Alias> line
774 Alias /theapp /tmp/somewhere
776 Then start your Catalyst application:
779 $ ./script/myapp_fastcgi -l /tmp/myapp-socket
781 If you want to use a TCP socket, simply change the C</tmp> to a
782 C<host:port> pair, both in Apache's configuration and on the command
783 line of your application.
787 Upgrading your application to newer Catalyst versions is quite simple. After
788 installing the new Catalyst package, just run:
790 B<catalyst.pl -scripts>
792 One level above your application directory. This will update the
793 scripts directory only, and leave the rest of your app alone, If you
794 wish to make use of other parts of Catalyst that have been updated,
795 leave off the B<-scripts> argument, this will cause .new files to
796 appear, for each module that has either been updated, or is different
797 to the original because you have changed it. To find out what these
800 B<diff MyApp/lib/MyApp/View/TT.pm MyApp/lib/MyApp/View/TT.pm.new>
802 for each of the changed files. (This is a Unix command, Windows users
803 will need to find some equivalent). Copy any changes you need into
804 your original file, then remove the .new files. (This makes life less
805 complicated when the next upgrade comes around.)
809 Jess Robinson, C<jrobinson@cpan.org>
810 Andrew Ford, C<A.Ford@ford-mason.co.uk>
811 Marcus Ramberg, C<mramberg@cpan.org>
812 Kieren Diment, C<kd@totaldatasolution.com>
814 Please send comments, corrections and suggestions for improvements to
819 Finish DBIC examples with templates and tested code. Make
820 /users/groups do something "useful"
826 This program is free software, you can redistribute it and/or modify
827 it under the same terms as Perl itself.