your C<use Catalyst> statement . However, you can also enable it using
environment variable, so you can (for example) get debug info without
modifying your application scripts. Just set C<CATALYST_DEBUG> or
-C<E<lt>MYAPP<gt>_DEBUG> to a true value.
+C<E<lt>MYAPPE<gt>_DEBUG> to a true value.
=head2 Sessions
sub add_item : Local {
my ( $self, $c ) = @_;
- my $item_id = $c->req->param("item");
+ my $item_id = $c->req->params->{item};
push @{ $c->session->{items} }, $item_id;
This is extensively covered in other documentation; see in particular
L<Catalyst::Plugin::Authentication> and the Authentication chapter
-of the Tutorial at L<Catalyst::Manual::Tutorial::Authorization>.
+of the Tutorial at L<Catalyst::Manual::Tutorial::06_Authorization>.
=head2 Pass-through login (and other actions)
},
},
},
- },
+ },
);
package MyApp::Controller::Root;
use Moose;
use namespace::autoclean;
-
+
BEGIN { extends 'Catalyst::Controller' }
-
+
__PACKAGE__->config(namespace => '');
-
+
sub login : Local {
my ($self, $c) = @_;
- if ( my $user = $c->req->param("user")
- and my $password = $c->req->param("password") )
+ if ( my $user = $c->req->params->{user}
+ and my $password = $c->req->param->{password} )
{
if ( $c->authenticate( username => $user, password => $password ) ) {
$c->res->body( "hello " . $c->user->name );
Under role based access control each user is allowed to perform any
number of roles. For example, at a zoo no one but specially trained
-personnel can enter the moose cage (Mynd you, møøse bites kan be
+personnel can enter the moose cage (Mynd you, møøse bites kan be
pretty nasti!). For example:
package Zoo::Controller::MooseCage;
sub feed_moose : Local {
my ( $self, $c ) = @_;
- $c->model( "Moose" )->eat( $c->req->param("food") );
+ $c->model( "Moose" )->eat( $c->req->params->{food} );
}
With this action, anyone can just come into the moose cage and feed
my ( $self, $c ) = @_;
if ( $c->check_roles( "moose_feeder" ) ) {
- $c->model( "Moose" )->eat( $c->req->param("food") );
+ $c->model( "Moose" )->eat( $c->req->params->{food} );
} else {
$c->stash->{error} = "unauthorized";
}
text if you wanted.
Most Catalyst applications use a template system to generate their HTML,
-and though there are several template systems available, Template
-Toolkit is probably the most popular.
+and though there are several template systems available,
+L<Template Toolkit|Template> is probably the most popular.
Once again, the Catalyst developers have done all the hard work, and
made things easy for the rest of us. Catalyst::View::TT provides the
=head3 Using XML::Feed
-A more robust solution is to use XML::Feed, as was done in the Catalyst
+A more robust solution is to use L<XML::Feed>, as was done in the Catalyst
Advent Calendar. Assuming we have a C<view> action that populates
'entries' with some DBIx::Class iterator, the code would look something
like this:
Controllers are the main point of communication between the web server
and your application. Here we explore some aspects of how they work.
-=head2 Extending RenderView (formerly DefaultEnd)
-
-The recommended approach for an C<end> action is to use
-L<Catalyst::Action::RenderView> (taking the place of
-L<Catalyst::Plugin::DefaultEnd>), which does what you usually need.
-However there are times when you need to add a bit to it, but don't want
-to write your own C<end> action.
-
-You can extend it like this:
-
-To add something to an C<end> action that is called before rendering
-(this is likely to be what you want), simply place it in the C<end>
-method:
-
- sub end : ActionClass('RenderView') {
- my ( $self, $c ) = @_;
- # do stuff here; the RenderView action is called afterwards
- }
-
-To add things to an C<end> action that are called I<after> rendering,
-you can set it up like this:
-
- sub render : ActionClass('RenderView') { }
-
- sub end : Private {
- my ( $self, $c ) = @_;
- $c->forward('render');
- # do stuff here
- }
-
=head2 Action Types
=head3 Introduction
=head3 Type attributes
Each action is a normal method in your controller, except that it has an
-L<attribute|http://search.cpan.org/~nwclark/perl-5.8.7/lib/attributes.pm>
+L<attribute|attributes>
attached. These can be one of several types.
Assume our Controller module starts with the following package declaration:
You can put root actions in your main MyApp.pm file, but this is deprecated,
please put your actions into your Root controller.
-=head3 More Information
+=head3 Flowchart
-L<http://dev.catalyst.perl.org/wiki/FlowChart>
+A graphical flowchart of how the dispatcher works can be found on the wiki at
+L<http://dev.catalyst.perl.org/attachment/wiki/WikiStart/catalyst-flow.png>.
-=head2 DRY Controllers with Chained actions.
+=head2 DRY Controllers with Chained actions
Imagine that you would like the following paths in your application:
=over
-=item B</cd/<ID>/track/<ID>>
+=item B<< /cd/<ID>/track/<ID> >>
Displays info on a particular track.
In the case of a multi-volume CD, this is the track sequence.
-=item B</cd/<ID>/volume/<ID>/track/<ID>>
+=item B<< /cd/<ID>/volume/<ID>/track/<ID> >>
Displays info on a track on a specific volume.
sub key1 : Chained('/')
+=head2 Extending RenderView (formerly DefaultEnd)
+
+The recommended approach for an C<end> action is to use
+L<Catalyst::Action::RenderView> (taking the place of
+L<Catalyst::Plugin::DefaultEnd>), which does what you usually need.
+However there are times when you need to add a bit to it, but don't want
+to write your own C<end> action.
+
+You can extend it like this:
+
+To add something to an C<end> action that is called before rendering
+(this is likely to be what you want), simply place it in the C<end>
+method:
+
+ sub end : ActionClass('RenderView') {
+ my ( $self, $c ) = @_;
+ # do stuff here; the RenderView action is called afterwards
+ }
+
+To add things to an C<end> action that are called I<after> rendering,
+you can set it up like this:
+
+ sub render : ActionClass('RenderView') { }
+
+ sub end : Private {
+ my ( $self, $c ) = @_;
+ $c->forward('render');
+ # do stuff here
+ }
+
+
+
=head1 Deployment
The recipes below describe aspects of the deployment process,
=head2 mod_perl Deployment
-mod_perl is the best solution for many applications, but we'll list some pros
-and cons so you can decide for yourself. The other production deployment
-option is FastCGI, for which see below.
+mod_perl is not the best solution for many applications, but we'll list some
+pros and cons so you can decide for yourself. The other (recommended)
+deployment option is FastCGI, for which see below.
=head3 Pros
=head4 Speed
-mod_perl is very fast and your app will benefit from being loaded in memory
+mod_perl is fast and your app will be loaded in memory
within each Apache process.
=head4 Shared memory for multiple apps
It is not possible to run two different versions of the same application in
the same Apache instance because the namespaces will collide.
+=head4 Cannot run different versions of libraries.
+
+If you have two differnet applications which run on the same machine,
+which need two different versions of a library then the only way to do
+this is to have per-vhost perl interpreters (with different library paths).
+This is entirely possible, but nullifies all the memory sharing benefits that
+you get from having multiple applications sharing the same interpreter.
+
=head4 Setup
Now that we have that out of the way, let's talk about setting up mod_perl
mod_fastcgi for Apache is a third party module, and can be found at
L<http://www.fastcgi.com/>. It is also packaged in many distributions,
-for example, libapache2-mod-fastcgi in Debian.
+for example, libapache2-mod-fastcgi in Debian. You will also need to install
+the L<FCGI> module from cpan.
+
+Important Note! If you experience difficulty properly rendering pages,
+try disabling Apache's mod_deflate (Deflate Module), e.g. 'a2dismod deflate'.
=head4 2. Configure your application
projects / catagits/Catalyst-Manual.git / blobdiff