},
},
},
- },
+ },
);
package MyApp::Controller::Root;
use Moose;
use namespace::autoclean;
-
+
BEGIN { extends 'Catalyst::Controller' }
-
+
__PACKAGE__->config(namespace => '');
-
+
sub login : Local {
my ($self, $c) = @_;
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;
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
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:
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