ready server (although you'll probably want to run it behind a front end proxy
if you end up using it).
-=back
-
=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
The best part is that Catalyst implements all this flexibility in a very
=item * B<MyApp/Model/>
-=item * B<MyApp/M/>
-
=item * B<MyApp/View/>
-=item * B<MyApp/V/>
-
=item * B<MyApp/Controller/>
-=item * B<MyApp/C/>
-
=back
-In older versions of Catalyst, the recommended practice (and the one
-automatically created by helper scripts) was to name the directories
-C<M/>, C<V/>, and C<C/>. Though these still work, they are deprecated
-and we now recommend the use of the full names.
-
=head4 Views
To show how to define views, we'll use an already-existing base class for the
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:
=item * B<Overriding the namespace>
-Note that I<< __PACKAGE__->config->(namespace => ... ) >> can be used to override the
+Note that C<< __PACKAGE__->config->(namespace => ... ) >> can be used to override the
current namespace when matching. So:
package MyApp::Controller::Example;