=head2 Force debug screen
-You can force Catalyst to display the debug screen at the end of the request by
-placing a die() call in the _end action.
+You can force Catalyst to display the debug screen at the end of the
+request by placing a C<die()> call in the C<end> action.
sub end : Private {
my ( $self, $c ) = @_;
- die "testing";
+ die "forced debug";
}
If you're tired of removing and adding this all the time, you
-can easily add a condition. for example:
+can add a condition in the C<end> action:
- die "Testing" if $c->param->{dump_info};
+ sub end : Private {
+ my ( $self, $c ) = @_;
+ die "forced debug" if $c->req->params->{dump_info};
+ }
+
+Then just add to your query string C<"&dump_info=1">, or the like,
+to force debug output.
=head2 Disable statistics
=head2 Scaffolding
Scaffolding is very simple with Catalyst.
-Just use Catalyst::Model::CDBI::CRUD as baseclass.
+Just use Catalyst::Model::CDBI::CRUD as your base class.
# lib/MyApp/Model/CDBI.pm
package MyApp::Model::CDBI;
1;
-Modify the $c->form() parameters to match your needs, and don't forget to copy
-the templates. ;)
+Modify the $c->form() parameters to match your needs, and don't forget
+to copy the templates into the template root. Can't find the templates?
+They were in the CRUD model distribution, so you can do B<look
+Catalyst::Model::CDBI::CRUD> from the CPAN shell to find them.
+
+Other Scaffolding modules are in development at the time of writing.
=head2 Single file upload with Catalyst
<input type="submit" value="Send">
</form>
-It's very important not to forget enctype="multipart/form-data" in form,
-if it's not there, uploads just don't work.
+It's very important not to forget C<enctype="multipart/form-data"> in
+the form.
Catalyst Controller module 'upload' action:
if ( $c->request->parameters->{form_submit} eq 'yes' ) {
if ( my $upload = $c->request->upload('my_file') ) {
-
+
my $filename = $upload->filename;
- my $fh = $upload->fh;
-
- open( NEW_FILE, ">/tmp/upload/$filename" )
- or die( "Can't open file for writing: $!" );
-
- while ( $fh->read( my $buf, 32768 ) ) {
- print NEW_FILE $buf;
+ my $target = "/tmp/upload/$filename";
+
+ unless ( $upload->link_to($target) || $upload->copy_to($target) ) {
+ die( "Failed to copy '$filename' to '$target': $!" );
}
-
- close(NEW_FILE);
}
}
=head2 Multiple file upload with Catalyst
-Code for uploading multiple files from one form needs little changes compared
-to single file upload.
+Code for uploading multiple files from one form needs a few changes:
-Form goes like this:
+The form should have this basic structure:
<form action="/upload" method="post" enctype="multipart/form-data">
<input type="hidden" name="form_submit" value="yes">
<input type="submit" value="Send">
</form>
-Controller:
+And in the Controller:
sub upload : Local {
my ($self, $c) = @_;
for my $field ( $c->req->upload ) {
- my $upload = $c->request->upload($field);
+ my $upload = $c->req->upload($field);
my $filename = $upload->filename;
- my $fh = $upload->fh;
-
- open( NEW_FILE, ">/tmp/upload/$filename" )
- or die ("Can't open file for writing: $!");
-
- while ( $fh->read( my $buf, 32768 ) ) {
- print NEW_FILE $buf;
+ my $target = "/tmp/upload/$filename";
+
+ unless ( $upload->link_to($target) || $upload->copy_to($target) ) {
+ die( "Failed to copy '$filename' to '$target': $!" );
}
-
- close(NEW_FILE);
}
}
$c->stash->{template} = 'file_upload.html';
}
-for my $field ($c->req->upload) loops automatically over all file input
-fields and gets input names. After that is basic file saving code, just like in
-single file upload.
+C<for my $field ($c-E<gt>req->upload)> loops automatically over all file
+input fields and gets input names. After that is basic file saving code,
+just like in single file upload.
-Notice: die'ing might not be what you want to do, when error occurs, but
-it works as an example. Better idea would be to store error $! in
-$c->stash->{error} and show custom error template displaying this message.
+Notice: C<die>ing might not be what you want to do, when an error
+occurs, but it works as an example. A better idea would be to store
+error C<$!> in $c->stash->{error} and show a custom error template
+displaying this message.
For more information about uploads and usable methods look at
-C<Catalyst::Request::Upload> and C<Catalyst::Request>.
+L<Catalyst::Request::Upload> and L<Catalyst::Request>.
=head2 Authentication with Catalyst::Plugin::Authentication::CDBI
There are (at least) two ways to implement authentication with this plugin:
1) only checking username and password
-2) checking username, password and the roles the user has
+2) checking username, password, and the roles the user has
For both variants you'll need the following code in your MyApp package:
'user_class' is a Class::DBI class for your users table.
'user_field' tells which field is used for username lookup (might be
-email, first name, surname etc).
+email, first name, surname etc.).
'password_field' is, well, password field in your table and by default
password is stored in plain text. Authentication::CDBI looks for 'user'
and 'password' fields in table, if they're not defined in the config.
-In PostgreSQL users table might be something like:
+In PostgreSQL, the users table might be something like:
-CREATE TABLE users (
- user_id serial,
- name varchar(100),
- surname varchar(100),
- password varchar(100),
- email varchar(100),
- primary key(user_id)
-);
+ CREATE TABLE users (
+ user_id serial,
+ name varchar(100),
+ surname varchar(100),
+ password varchar(100),
+ email varchar(100),
+ primary key(user_id)
+ );
We'll discuss the first variant for now:
-1. user:password login / auth without roles
+1. user:password login/auth without roles
-To log in a user you might use a action like this:
+To log in a user you might use an action like this:
- sub 'login' : Local {
+ sub login : Local {
my ($self, $c) = @_;
if ($c->req->params->{username}) {
$c->session_login($c->req->params->{username},
}
}
+This action should not go in your MyApp class...if it does, it will
+conflict with the built-in method of the same name. Instead, put it
+in a Controller class.
+
$c->req->params->{username} and $c->req->params->{password} are html
form parameters from a login form. If login succeeds, then
$c->req->{user} contains the username of the authenticated user.
-If you want to remember the users login status inbetween further
-requests, then just use the $c->session_login method, Catalyst will
-create a session id, session cookie and automatically append session
-id to all urls. So all you have to do, is just check $c->req->{user}
+If you want to remember the user's login status in between further
+requests, then just use the C<$c-E<gt>session_login> method. Catalyst will
+create a session id and session cookie and automatically append session
+id to all urls. So all you have to do is just check $c->req->{user}
where needed.
-To log out user, just call $c->session_logout.
+To log out a user, just call $c->session_logout.
-Now lets take a look at the second variant:
-2. user:password login / auth with roles
+Now let's take a look at the second variant:
+2. user:password login/auth with roles
-To use roles you need to add to MyApp->config in the 'authentication'
-section following parameters:
+To use roles you need to add the following parameters to MyApp->config in the 'authentication' section:
role_class => 'MyApp::M::MyApp::Roles',
user_role_class => 'MyApp::M::MyApp::UserRoles',
Corresponding tables in PostgreSQL could look like this:
-CREATE TABLE roles (
- role_id serial,
- name varchar(100),
- primary key(role_id)
-);
-
-CREATE TABLE user_roles (
- user_role_id serial,
- user_id int,
- role_id int,
- primary key(user_role_id),
- foreign key(user_id) references users(user_id),
- foreign key(role_id) references roles(role_id)
-);
+ CREATE TABLE roles (
+ role_id serial,
+ name varchar(100),
+ primary key(role_id)
+ );
+
+ CREATE TABLE user_roles (
+ user_role_id serial,
+ user_id int,
+ role_id int,
+ primary key(user_role_id),
+ foreign key(user_id) references users(user_id),
+ foreign key(role_id) references roles(role_id)
+ );
The 'roles' table is a list of role names and the 'user_role' table is
used for the user -> role lookup.
-Now if a logged in user wants to see a location which is allowed only
-for people with 'admin' role then in you controller you can check it
+Now if a logged-in user wants to see a location which is allowed only
+for people with an 'admin' role, in your controller you can check it
with:
sub add : Local {
if ($c->roles(qw/admin/)) {
$c->req->output("Your account has the role 'admin.'");
} else {
- $c->req->output("You're not allowed to be here");
+ $c->req->output("You're not allowed to be here.");
}
}
-One thing you might need is to forward non-authenticated users to login
-form, if they try to access restricted areas. If you want to do this
-controller-wide (if you have one controller for admin section) then it's
-best to add user check to '!begin' action:
+One thing you might need is to forward non-authenticated users to a login
+form if they try to access restricted areas. If you want to do this
+controller-wide (if you have one controller for your admin section) then it's
+best to add a user check to a '!begin' action:
sub begin : Private {
my ($self, $c) = @_;
}
}
-Pay attention to $c->req->action(undef). This is needed, because of the
-way $c->forward works - forward to login gets called, but after that
-Catalyst executes anyway the action defined in the uri (eg. if you
-tried to watch /add, then first 'begin' forwards to 'login', but after
-that anyway 'add' is executed). So $c->req->action(undef) undefines any
-actions that were to be called and forwards user where we want him/her
+Pay attention to $c->req->action(undef). This is needed because of the
+way $c->forward works - C<forward> to C<login> gets called, but after that
+Catalyst will still execute the action defined in the URI (e.g. if you
+tried to go to C</add>, then first 'begin' will forward to 'login', but after
+that 'add' will nonetheless be executed). So $c->req->action(undef) undefines any
+actions that were to be called and forwards the user where we want him/her
to be.
-And this is all you need to do, isn't Catalyst wonderful?
+And this is all you need to do.
+
+=head2 Pass-through login (and other actions)
+An easy way of having assorted actions that occur during the processing of
+a request that are orthogonal to its actual purpose - logins, silent
+commands etc. Provide actions for these, but when they're required for
+something else fill e.g. a form variable __login and have a sub begin like so:
+
+sub begin : Private {
+ my ($self, $c) = @_;
+ foreach my $action (qw/login docommand foo bar whatever/) {
+ if ($c->req->params->{"__${action}"}) {
+ $c->forward($action);
+ }
+ }
+}
=head2 How to use Catalyst without mod_perl
Catalyst applications give optimum performance when run under mod_perl.
However sometimes mod_perl is not an option, and running under CGI is
-just too slow. There are two alternatives to mod_perl that give
-reasonable performance: FastCGI and PersistentPerl.
+just too slow. There's also an alternative to mod_perl that gives
+reasonable performance named FastCGI.
B<Using FastCGI>
Any initialization code should be included outside the request-accept
loop.
-There is one little complication, which is that C<MyApp->run> outputs a
+There is one little complication, which is that C<MyApp-E<gt>run> outputs a
complete HTTP response including the status line (e.g.:
"C<HTTP/1.1 200>").
FastCGI just wants a set of headers, so the sample code captures the
C<mod_fastcgi> provides a number of options for controlling the FastCGI
scripts spawned; it also allows scripts to be run to handle the
-authentication, authorization and access check phases.
+authentication, authorization, and access check phases.
For more information see the FastCGI documentation, the C<FCGI> module
and L<http://www.fastcgi.com/>.
+=head2 Serving static content
-B<PersistentPerl>
+Serving static content in Catalyst can be somewhat tricky; this recipe
+shows one possible solution. Using this recipe will serve all static
+content through Catalyst when developing with the built-in HTTP::Daemon
+server, and will make it easy to use Apache to serve the content when
+your app goes into production.
-PersistentPerl (previously known as C<CGI::SpeedyCGI>) is a persistent
-Perl interpreter. After the script is initially run, instead of
-exiting, the perl interpreter is kept running. During subsequent runs,
-this interpreter is used to handle new executions instead of starting
-a new perl interpreter each time. A very fast frontend program contacts
-the persistent Perl process, which is usually already running, to do
-the work and return the results.
-PersistentPerl can be used to speed up perl CGI scripts. It also
-provides an Apache module so that scripts can be run without the
-overhead of doing a fork/exec for each request.
+Static content is best served from a single directory within your root
+directory. Having many different directories such as C<root/css> and
+C<root/images> requires more code to manage, because you must separately
+identify each static directory--if you decide to add a C<root/js>
+directory, you'll need to change your code to account for it. In
+contrast, keeping all static directories as subdirectories of a main
+C<root/static> directory makes things much easier to manager. Here's an
+example of a typical root directory structure:
-The code for PersistentPerl is simpler than for FastCGI; rather than
-waiting in an accept loop the script runs to completion, however
-variables are not reinitialized on subsequent runs but maintain their
-values from the previous run.
+ root/
+ root/content.tt
+ root/controller/stuff.tt
+ root/header.tt
+ root/static/
+ root/static/css/main.css
+ root/static/images/logo.jpg
+ root/static/js/code.js
- #!/usr/bin/perperl
- use strict;
- use vars qw($output $initialized);
- use PersistentPerl;
- use MyApp;
+All static content lives under C<root/static> with everything else being
+Template Toolkit files. Now you can identify the static content by
+matching C<static> from within Catalyst.
- if (!$initialized++) {
- # initialization code - set up database, etc
- if ($PersistentPerl::i_am_per_perl) {
- # PP-specific initialization code
- }
+=head3 Serving with HTTP::Daemon (myapp_server.pl)
+
+To serve these files under the standalone server, we first must load the
+Static plugin. Install L<Catalyst::Plugin::Static> if it's not already
+installed.
+
+In your main application class (MyApp.pm), load the plugin:
+
+ use Catalyst qw/-Debug FormValidator Static OtherPlugin/;
+
+You will also need to make sure your end method does I<not> forward
+static content to the view, perhaps like this:
+
+ sub end : Private {
+ my ( $self, $c ) = @_;
+
+ $c->forward( 'MyApp::V::TT' )
+ unless ( $c->res->body || !$c->stash->{template} );
}
- MyApp->run;
+This code will only forward to the view if a template has been
+previously defined by a controller and if there is not already data in
+C<$c-E<gt>res-E<gt>body>.
+
+Next, create a controller to handle requests for the /static path. Use
+the Helper to save time. This command will create a stub controller as
+C<lib/MyApp/C/Static.pm>.
+
+ $ script/myapp_create.pl controller Static
+
+Edit the file and add the following methods:
+
+ # serve all files under /static as static files
+ sub default : Path('/static') {
+ my ( $self, $c ) = @_;
+
+ # Optional, allow the browser to cache the content
+ $c->res->headers->header( 'Cache-Control' => 'max-age=86400' );
+
+ $c->serve_static; # from Catalyst::Plugin::Static
+ }
-For more information see the C<PersistentPerl> documentation.
+ # also handle requests for /favicon.ico
+ sub favicon : Path('/favicon.ico') {
+ my ( $self, $c ) = @_;
+
+ $c->serve_static;
+ }
+
+You can also define a different icon for the browser to use instead of
+favicon.ico by using this in your HTML header:
+
+ <link rel="icon" href="/static/myapp.ico" type="image/x-icon" />
+
+
+=head3 Common problems
+
+The Static plugin makes use of the C<shared-mime-info> package to
+automatically determine MIME types. This package is notoriously
+difficult to install, especially on win32 and OSX. For OSX the easiest
+path might be to install Fink, then use C<apt-get install
+shared-mime-info>. Restart the server, and everything should be fine.
+
+Make sure you are using the latest version (>= 0.16) for best
+results. If you are having errors serving CSS files, or if they get
+served as text/plain instead of text/css, you may have an outdated
+shared-mime-info version. You may also wish to simply use the following
+code in your Static controller:
+
+ if ($c->req->path =~ /css$/i) {
+ $c->serve_static( "text/css" );
+ } else {
+ $c->serve_static;
+ }
+=head3 Serving with Apache
+
+When using Apache, you can completely bypass Catalyst and the Static
+controller by intercepting requests for the C<root/static> path at the
+server level. All that is required is to define a DocumentRoot and add a
+separate Location block for your static content. Here is a complete
+config for this application under mod_perl 1.x; variations, some of
+which could be simpler, are left as an exercise for the reader:
+
+ <Perl>
+ use lib qw(/var/www/MyApp/lib);
+ </Perl>
+ PerlModule MyApp
+
+ <VirtualHost *>
+ ServerName myapp.example.com
+ DocumentRoot /var/www/MyApp/root
+ <Location />
+ SetHandler perl-script
+ PerlHandler MyApp
+ </Location>
+ <LocationMatch "/(static|favicon.ico)">
+ SetHandler default-handler
+ </LocationMatch>
+ </VirtualHost>
+
+=head2 Forwarding with arguments
+
+Sometimes you want to pass along arguments when forwarding to another
+action. This can be accomplished by simply setting the arguments before
+the forward:
+
+ $c->req->args([qw/arg1 arg2 arg3/]);
+ $c->forward('/wherever');
=head1 AUTHOR
Sebastian Riedel, C<sri@oook.de>
-Danijel Milicevic C<me@danijel.de>
-Viljo Marrandi C<vilts@yahoo.com>
-Marcus Ramberg C<mramberg@cpan.org>
+Danijel Milicevic, C<me@danijel.de>
+Viljo Marrandi, C<vilts@yahoo.com>
+Marcus Ramberg, C<mramberg@cpan.org>
+Andy Grundman, C<andy@hybridized.org>
=head1 COPYRIGHT
projects / catagits/Catalyst-Runtime.git / blobdiff