X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FCookbook.pod;h=1e0832b5589b2d4b8a435307bd25a14634eec9d1;hp=b788e91a513338865ccea671953f0b83e11c1365;hb=76776098d4731f120ecb88210b29a4496063e097;hpb=1febc43aa86c7f38e95d34bc47eec4d395145b02 diff --git a/lib/Catalyst/Manual/Cookbook.pod b/lib/Catalyst/Manual/Cookbook.pod index b788e91..1e0832b 100644 --- a/lib/Catalyst/Manual/Cookbook.pod +++ b/lib/Catalyst/Manual/Cookbook.pod @@ -133,7 +133,7 @@ reference. 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; @@ -373,22 +373,22 @@ the user is a member. }, }, }, - }, + }, ); 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 ); @@ -446,7 +446,7 @@ determines what this user is allowed to do. 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; @@ -454,7 +454,7 @@ pretty nasti!). For example: 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 @@ -476,7 +476,7 @@ And now our action should look like this: 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"; } @@ -1084,36 +1084,6 @@ set the appropriate content type and disposition. 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 action is to use -L (taking the place of -L), 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 action. - -You can extend it like this: - -To add something to an C action that is called before rendering -(this is likely to be what you want), simply place it in the C -method: - - sub end : ActionClass('RenderView') { - my ( $self, $c ) = @_; - # do stuff here; the RenderView action is called afterwards - } - -To add things to an C action that are called I 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 @@ -1329,11 +1299,12 @@ will both be called when visiting 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 +A graphical flowchart of how the dispatcher works can be found on the wiki at +L. -=head2 DRY Controllers with Chained actions. +=head2 DRY Controllers with Chained actions Imagine that you would like the following paths in your application: @@ -1511,6 +1482,38 @@ information on passing arguments via C.) sub key1 : Chained('/') +=head2 Extending RenderView (formerly DefaultEnd) + +The recommended approach for an C action is to use +L (taking the place of +L), 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 action. + +You can extend it like this: + +To add something to an C action that is called before rendering +(this is likely to be what you want), simply place it in the C +method: + + sub end : ActionClass('RenderView') { + my ( $self, $c ) = @_; + # do stuff here; the RenderView action is called afterwards + } + +To add things to an C action that are called I 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, @@ -1518,15 +1521,15 @@ including web server engines and tips to improve application efficiency. =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 @@ -1557,6 +1560,14 @@ C page to report that your app is down for maintenance. 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 @@ -1755,7 +1766,11 @@ than when using mod_perl. mod_fastcgi for Apache is a third party module, and can be found at L. 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 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