ready server (although you'll probably want to run it behind a front end proxy
if you end up using it).
+=item * PSGI Support
+
+Starting with Catalyst version 5.9 Catalyst ships with L<PSGI> integration
+for even more powerful and flexible testing and deployment options. See
+L<Catalyst::PSGI> for details.
+
=back
=head3 Simplicity
use base qw/Catalyst::Controller/;
- sub login : Path("login") { }
+ sub sign_in : Path("sign-in") { }
sub new_password : Path("new-password") { }
- sub logout : Path("logout") { }
+ sub sign_out : Path("sign-out") { }
package MyApp::Controller::Catalog;
model or view code. Instead you use the C<ACCEPT_CONTEXT> subroutine
to grab the bits of the context object that you need, and provide
accessors to them in the model. This ensures that C<$c> is only in
-scope where it is neaded which reduces maintenance and debugging
+scope where it is needed which reduces maintenance and debugging
headaches. So, if for example you needed two
L<Catalyst::Model::DBIC::Schema> models in the same Catalyst model
code, you might do something like this:
1;
-Matches http://localhost:3000/foo - that is, the action is mapped
-directly to the controller namespace, ignoring the function name.
+Matches http://localhost:3000/bar - that is, the action is mapped
+directly to the method name, ignoring the controller namespace.
C<:Global> always matches from the application root: it is simply
shorthandfor C<:Path('/methodname')>. C<:Local> is shorthand for
used to make sense are now largely replaced by the C<Chained> dispatch
type, or by empty C<Path> declarations on an controller action. C<Global>
is still included in Catalyst for backwards compatibility, although
-legitimate use-cases for it may still exist (but nobody can.
+legitimate use-cases for it may still exist.
=item * Changing handler behaviour: eating arguments (C<:Args>)