=item * B<Unrestrained URL-to-Action Dispatching>
-Catalyst allows you to dispatch any URLs to any application L<Actions>,
+Catalyst allows you to dispatch any URLs to any application L</Actions>,
even through regular expressions! Unlike most other frameworks, it
doesn't require mod_rewrite or class and method names in URLs.
=item * B<Building Block Interface>
Components interoperate very smoothly. For example, Catalyst
-automatically makes a L<context> object available to every
+automatically makes a L</Context> object available to every
component. Via the context, you can access the request object, share
data between components, and control the flow of your
application. Building a Catalyst application feels a lot like snapping
Now visit these locations with your favorite browser or user agent to see
Catalyst in action:
+(NOTE: Although we create a controller here, we don't actually use it.
+Both of these URLs should take you to the welcome page.)
+
+
=over 4
=item http://localhost:3000/
Catalyst automatically blesses a Context object into your application
class and makes it available everywhere in your application. Use the
-Context to directly interact with Catalyst and glue your L<Components>
+Context to directly interact with Catalyst and glue your L</Components>
together. For example, if you need to use the Context from within a
Template Toolkit template, it's already there:
For both LocalRegex and Regex actions, if you use capturing parentheses
to extract values within the matching URL, those values are available in
-the C<$c-E<gt>req-E<gt>snippets> array. In the above example, "widget23"
+the C<$c-E<gt>req-E<gt>captures> array. In the above example, "widget23"
would capture "23" in the above example, and
-C<$c-E<gt>req-E<gt>snippets-E<gt>[0]> would be "23". If you want to pass
+C<$c-E<gt>req-E<gt>captures-E<gt>[0]> would be "23". If you want to pass
arguments at the end of your URL, you must use regex action keys. See
L</URL Path Handling> below.
from elsewhere, be reached with
C<$c-E<gt>forward('/catalog/order/process/bar')>.
+=item * B<Args>
+
+Args is not an action type per se, but an action modifier - it adds a match
+restriction to any action it's provided to, requiring only as many path parts
+as are specified for the action to be valid - for example in
+MyApp::Controller::Foo,
+
+ sub bar :Local
+
+would match any URL starting /foo/bar/. To restrict this you can do
+
+ sub bar :Local :Args(1)
+
+to only match /foo/bar/*/
+
=back
B<Note:> After seeing these examples, you probably wonder what the point
individual controllers.
If C<default> isn't acting how you would expect, look at using a
-L<Literal> C<Path> action (with an empty path string). The difference is
+L</Literal> C<Path> action (with an empty path string). The difference is
that C<Path> takes arguments relative from the namespace and C<default>
I<always> takes arguments relative from the root, regardless of what
controller it's in.
=head3 Components
Catalyst has an uncommonly flexible component system. You can define as
-many L<Models>, L<Views>, and L<Controllers> as you like.
+many L</Models>, L</Views>, and L</Controllers> as you like.
All components must inherit from L<Catalyst::Base>, which provides a
simple class structure and some common class methods like C<config> and
use base qw/Catalyst::Model::DBIC::Schema/;
__PACKAGE__->config(
schema_class => 'Some::DBIC::Schema',
- connect_info => ['dbi:SQLite:foo.db', '', '', {AutoCommit=>1}];
+ connect_info => ['dbi:SQLite:foo.db', '', '', {AutoCommit=>1}]
);
1;
package MyApp::Controller::Login;
- sub sign-in : Local { }
- sub new-password : Local { }
- sub sign-out : Local { }
+ use base qw/Catalyst::Controller/;
+
+ sub sign_in : Path("sign-in") { }
+ sub new_password : Path("new-password") { }
+ sub sign_out : Path("sign-out") { }
package MyApp::Controller::Catalog;
+ use base qw/Catalyst::Controller/;
+
sub view : Local { }
sub list : Local { }
package MyApp::Controller::Cart;
+ use base qw/Catalyst::Controller/;
+
sub add : Local { }
sub update : Local { }
sub order : Local { }
+Note that you can also supply attributes via the Controller's config so long
+as you have at least one attribute on a subref to be exported (:Action is
+commonly used for this) - for example the following is equivalent to the same
+controller above
+
+ package MyApp::Controller::Login;
+
+ use base qw/Catalyst::Controller/;
+
+ __PACKAGE__->config(
+ actions => {
+ 'sign_in' => { Path => 'sign-in' },
+ 'new_password' => { Path => 'new-password' },
+ 'sign_out' => { Path => 'sign-out' },
+ },
+ );
+
+ sub sign_in : Action { }
+ sub new_password : Action { }
+ sub sign_out : Action { }
+
=head3 Testing
Catalyst has a built-in http server for testing! (Later, you can easily