features of how Catalyst works and shows how to get a simple application
up and running quickly. For an introduction (without code) to Catalyst
itself, and why you should be using it, see L<Catalyst::Manual::About>.
+For a systematic step-by-step introduction to writing an application
+with Catalyst, see L<Catalyst::Manual::Tutorial>.
=head2 What is Catalyst?
Catalyst is an elegant web application framework, extremely flexible yet
-extremely simple. It's similar to Ruby on Rails, Spring (Java) and
-L<Maypole>, upon which it was originally based.
+extremely simple. It's similar to Ruby on Rails, Spring (Java), and
+L<Maypole>, upon which it was originally based. Its most important
+design philosphy is to provide easy access to all the tools you need to
+develop web applications, with few restrictions on how you need to use
+these tools. Under Catalyst, it is always possible to do things in a
+different way. However, this does mean that it is always possible to do
+things in a different way. Other web frameworks are simpler to use and
+easy to get up and running, but achieve this by locking the programmer
+into a single set of tools. Catalyst's emphasis on flexibility means
+that you have to think more to use it. We view this as a feature.
=head3 MVC
=item * B<Model>
-Access and modify content (data). L<Class::DBI>, L<DBIx::Class>,
-L<Plucene>, L<Net::LDAP>...
+Access and modify content (data). L<DBIx::Class>, L<Class::DBI>,
+L<Xapian>, L<Net::LDAP>...
=item * B<View>
=item * B<Controller>
Control the whole request phase, check parameters, dispatch actions, flow
-control. Catalyst!
+control. Catalyst itself!
=back
-If you're unfamiliar with MVC and design patterns, you may want to check
-out the original book on the subject, I<Design Patterns>, by Gamma,
-Helm, Johnson, and Vlissides, also known as the Gang of Four (GoF). You
-can also just Google it. Many, many web application frameworks are
-based on MVC, including all those listed above.
+If you're unfamiliar with MVC and design patterns, you may want to
+check out the original book on the subject, I<Design Patterns>, by
+Gamma, Helm, Johnson, and Vlissides, also known as the Gang of Four
+(GoF). Many, many web application frameworks are based on MVC, which
+is becoming a popular design method for web applications.
=head3 Flexibility
=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
=item * B<Pre-Built Components for Popular Modules>
-See L<Catalyst::Model::CDBI> for L<Class::DBI>, or L<Catalyst::View::TT>
-for L<Template Toolkit|Template>.
+See L<Catalyst::Model::DBIC::Schema> for L<DBIx::Class>, or
+L<Catalyst::View::TT> for L<Template Toolkit|Template>.
=item * B<Built-in Test Framework>
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/
=back
-Dead easy!
+Easy!
=head2 How It Works
In addition to the Model, View, and Controller components, there's a
single class that represents your application itself. This is where you
-configure your application, load plugins, define application-wide
-actions, and extend Catalyst.
+configure your application, load plugins, and extend Catalyst.
package MyApp;
# You can put anything else you want in here:
my_configuration_variable => 'something',
);
-
- sub default : Private {
- my ( $self, $context ) = @_;
- $context->response->body('Catalyst rocks!');
- }
-
1;
-For most applications, Catalyst requires you to define only one config
-parameter:
+In older versions of Catalyst, the application class was where you put
+global actions. However, as of version 5.66, the recommended practice is
+to place such actions in a special Root controller (see #####, below),
+to avoid namespace collisions.
=over 4
=item * B<name>
-Name of your application.
+The name of your application.
=back
whatever you need. You can access them anywhere in your application via
C<$context-E<gt>config-E<gt>{$param_name}>.
+###### We need a short section on configuration here.
+
=head3 Context
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:
=item * L<Catalyst::Log>
$c->log
-
$c->log->debug('Something happened');
$c->log->info('Something you should know');
$c->stash
$c->stash->{foo} = 'bar';
+ $c->stash->{baz} = {baz => 'qox'};
+ $c->stash->{fred} = [qw/ wilma pebbles/];
+
+and so on.
=back
=head3 Actions
-A Catalyst controller is defined by its actions. An action is a sub with
-a special attribute. You've already seen some examples of actions in
-this document. The URL (for example http://localhost.3000/foo/bar)
-consists of two parts, the base (http://localhost:3000/ in this example)
-and the path (foo/bar). Please note that the trailing slash after the
-hostname[:port] always belongs to base and not to the action.
+A Catalyst controller is defined by its actions. An action is a
+subroutine with a special attribute. You've already seen some examples
+of actions in this document. The URL (for example
+http://localhost.3000/foo/bar) consists of two parts, the base
+(http://localhost:3000/ in this example) and the path (foo/bar). Please
+note that the trailing slash after the hostname[:port] always belongs to
+base and not to the action.
+
+=over 4
+
+=item * B<Application Wide Actions>
+
+Actions which are called at the root level of the application
+(e.g. http://localhost:3000/ ) go in MyApp::Controller::Root, like
+this:
+
+ package MyApp::Controller::Root;
+ use base 'Catalyst::Controller';
+ # Sets the actions in this controller to be registered with no prefix
+ # so they function identically to actions created in MyApp.pm
+ __PACKAGE__->config->{namespace} = '';
+ sub default : Private {
+ my ( $self, $context ) = @_;
+ $context->response->body('Catalyst rocks!');
+ }
+ 1;
+
+=back
+
+=head4 Action types
Catalyst supports several types of actions:
=over 4
-=item * B<Literal>
+=item * B<Literal> (B<Path> actions)
package MyApp::Controller::My::Controller;
sub bar : Path('foo/bar') { }
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.
-=item * B<Top-level>
+=item * B<Top-level> (B<Global>)
- package MyApp;
+ package MyApp::Controller::Foo;
sub foo : Global { }
-Matches http://localhost:3000/foo. The function name is mapped directly
-to the application base.
+Matches http://localhost:3000/foo. The function name is mapped
+directly to the application base. You can provide an equivalent
+function in this case by doing the following:
-=item * B<Namespace-Prefixed>
+ package MyApp::Controller::Root
+ sub foo : Local { }
+
+=item * B<Namespace-Prefixed> (B<Local>)
package MyApp::Controller::My::Controller;
sub foo : Local { }
explanation of the pre-defined meaning of Catalyst component class
names.
+=item * B<Chained>
+
+Catalyst also provides a method to build and dispatch chains of actions,
+like
+
+ sub foo : Chained : CaptureArgs(1) {
+ my ( $self, $c, $arg ) = @_;
+ ...
+ }
+
+ sub bar : Chained('foo') : Args(1) {
+ my ( $self, $c, $arg ) = @_;
+ ...
+ }
+
+to handle a C</foo/*/bar/*> path. For more information about this dispatch
+type, please read L<Catalyst::DispatchType::Chained>.
+
=item * B<Private>
sub foo : Private { }
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
-is of defining names for regex and path actions. Actually, every public
-action is also a private one, so you have one unified way of addressing
-components in your C<forward>s.
+is of defining names for regex and path actions. Every public action is
+also a private one, so you have one unified way of addressing components
+in your C<forward>s.
=head4 Built-in Private Actions
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.
$c->res->body( $c->stash->{message} );
}
-A C<forward> does not create a new request, so your request
-object (C<$c-E<gt>req>) will remain unchanged. This is a
-key difference between using C<forward> and issuing a
-redirect.
+A C<forward> does not create a new request, so your request object
+(C<$c-E<gt>req>) will remain unchanged. This is a key difference between
+using C<forward> and issuing a redirect.
You can pass new arguments to a C<forward> by adding them
in an anonymous array. In this case C<$c-E<gt>req-E<gt>args>
sub check_message : Private {
my ( $self, $c ) = @_;
- my $first_argument = $c->req->args[0]; # now = 'test1'
+ my $first_argument = $c->req->args->[0]; # now = 'test1'
# do something...
}
=head3 Components
-Catalyst has an uncommonly flexible component system. You can define as many
-L<Models>, L<Views>, and L<Controllers> as you like.
+Catalyst has an uncommonly flexible component system. You can define as
+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 C<new>
-(constructor).
+All components must inherit from L<Catalyst::Base>, which provides a
+simple class structure and some common class methods like C<config> and
+C<new> (constructor).
package MyApp::Controller::Catalog;
Controllers. Catalyst automatically discovers and instantiates them
when you call C<setup> in the main application. All you need to do is
put them in directories named for each Component type. Notice that you
-can use some very terse aliases for each one.
+can use a terse alias for each one.
=over 4
=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, 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
=head4 Models
To show how to define models, again we'll use an already-existing base
-class, this time for L<Class::DBI>: L<Catalyst::Model::CDBI>.
+class, this time for L<DBIx::Class>: L<Catalyst::Model::DBIC::Schema>.
+We'll also need L<DBIx::Class::Schema::Loader>.
But first, we need a database.
% sqlite /tmp/myapp.db < myapp.sql
-Now we can create a CDBI component for this database.
+Now we can create a DBIC::SchemaLoader component for this database.
- package MyApp::Model::CDBI;
+ script/myapp_create.pl model DBIC DBIC::SchemaLoader 'dbi:SQLite:/tmp/myapp.db'
- use strict;
- use base 'Catalyst::Model::CDBI';
+L<DBIx::Class::Schema::Loader> automatically loads table layouts and
+relationships. Use the stash to pass data to your templates.
- __PACKAGE__->config(
- dsn => 'dbi:SQLite:/tmp/myapp.db',
- relationships => 1
- );
-
- 1;
-
-Catalyst automatically loads table layouts and relationships. Use the
-stash to pass data to your templates.
-
- package MyApp;
-
- use strict;
- use Catalyst '-Debug';
-
- __PACKAGE__->config(
- name => 'My Application',
- root => '/home/joeuser/myapp/root'
- );
+We add the following to MyApp/Controller/Root.pm
- __PACKAGE__->setup;
+ sub view : Global {
+ my ( $self, $c, $id ) = @_;
+
+ $c->stash->{item} = $c->model('DBIC::Foo')->find($id);
+ }
+ 1;
+
sub end : Private {
my ( $self, $c ) = @_;
+
$c->stash->{template} ||= 'index.tt';
- $c->forward('MyApp::View::TT');
- }
-
- sub view : Global {
- my ( $self, $c, $id ) = @_;
- $c->stash->{item} = MyApp::Model::CDBI::Foo->retrieve($id);
+ $c->forward( $c->view('TT') );
}
- 1;
+We then create a new template file "root/index.tt" containing:
- # Then, in a TT template:
- The id is [% item.data %]
+ The Id's data is [% item.data %]
Models do not have to be part of your Catalyst application; you
can always call an outside module that serves as your Model:
# in a Controller
sub list : Local {
my ( $self, $c ) = @_;
+
$c->stash->{template} = 'list.tt';
- use Some::Outside::CDBI::Module;
- my @records = Some::Outside::CDBI::Module->retrieve_all;
+
+ use Some::Outside::DBIC::Module;
+ my @records = Some::Outside::DBIC::Module->search({
+ artist => 'sri',
+ });
+
$c->stash->{records} = \@records;
}
in a cron job), it's trivial to write a simple component in
Catalyst that slurps in an outside Model:
- package MyApp::Model::Catalog;
- use base qw/Catalyst::Base Some::Other::CDBI::Module::Catalog/;
+ package MyApp::Model::DB;
+ use base qw/Catalyst::Model::DBIC::Schema/;
+ __PACKAGE__->config(
+ schema_class => 'Some::DBIC::Schema',
+ connect_info => ['dbi:SQLite:foo.db', '', '', {AutoCommit=>1}]
+ );
1;
-and that's it! Now C<Some::Other::CDBI::Module::Catalog> is part of your
-Cat app as C<MyApp::Model::Catalog>.
+and that's it! Now C<Some::DBIC::Schema> is part of your
+Cat app as C<MyApp::Model::DB>.
=head4 Controllers
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 Models
+
+Models are providers of data. This data could come from anywhere - a search
+engine index, a database table, etc. Typically the data source does not have
+much to do with web applications or Catalyst - it could be used to write an
+offline report generator or a command line tool just the same.
+
+The common approach to writing a Catalyst-style model for your application is
+wrapping a generic model (e.g. L<DBIx::Class::Schema>, a bunch of XMLs, or
+anything really) with an object that contains configuration data, convenience
+methods, and so forth.
+
+#### editor: move this part to =head3 Components somehow, right after this
+#### section - this will require deeply rephrasing this paragraph.
+
+Technically, within Catalyst a model is a B<component> - an instance of the
+model's class belonging to the application. It is important to stress that the
+lifetime of these objects is per application, not per request.
+
+While the model base class (L<Catalyst::Model>) provides things like C<config>
+and stuff to better integrate the model into the application, sometimes this is
+not enough, and the model requires access to C<$c> itself.
+
+Situations where this need might arise include:
+
+=over 4
+
+=item *
+
+Interacting with another model
+
+=item *
+
+Using per-request data to control behavior
+
+=item *
+
+Using plugins in (for example L<Catalyst::Plugin::Cache>).
+
+=back
+
+From a style perspective usually it's bad to make your model "too smart"
+about things - it should worry about business logic and leave the
+integration details to the controllers. If, however, you find that it
+does not make sense at all to use an auxillary controller around the
+model, and the model's need to access C<$c> cannot be sidestepped, there
+exists a power tool called C<ACCEPT_CONTEXT>.
+
+#### editor note: this part is "generic" - it also applies to views and
+#### controllers.
+
+=head3 ACCEPT_CONTEXT
+
+Whenever you call $c->component("Foo") you get back an object - the
+instance of the model. If the component supports the C<ACCEPT_CONTEXT>
+method instead of returning the model itself, the return value of C<<
+$model->ACCEPT_CONTEXT( $c ) >> will be used.
+
+This means that whenever your model/view/controller needs to talk to C<$c> it
+gets a chance to do this when it's needed.
+
+A typical C<ACCEPT_CONTEXT> method will either clone the model and return one
+with the context object set, or it will return a thin wrapper that contains
+C<$c> and delegates to the per-application model object.
+
+A typical C<ACCEPT_CONTEXT> method could look like this:
+
+ sub ACCEPT_CONTEXT {
+ my ( $self, $c, @extra_arguments ) = @_;
+ bless { %$self, c => $c }, ref($self);
+ }
+
+effectively treating $self as a B<prototype object> that gets a new parameter.
+C<@extra_arguments> comes from any trailing arguments to
+C<< $c->component( $bah, @extra_arguments ) >> (or C<< $c->model(...) >>,
+C<< $c->view(...) >> etc).
+
+The life time of this value is B<per usage>, and not per request. To make this
+per request you can use the following technique:
+
+Add a field to C<$c>, like C<my_model_instance>. Then write your
+C<ACCEPT_CONTEXT> method to look like this:
+
+ sub ACCEPT_CONTEXT {
+ my ( $self, $c ) = @_;
+
+ if ( my $per_request = $c->my_model_instance ) {
+ return $per_request;
+ } else {
+ my $new_instance = bless { %$self, c => $c }, ref($self);
+ Scalar::Util::weaken($new_instance->{c}); # or we have a circular reference
+ $c->my_model_instance( $new_instance );
+ return $new_instance;
+ }
+ }
+
+
=head3 Testing
-Catalyst has a built-in http server for testing! (Later, you can easily
-use a more powerful server, e.g. Apache/mod_perl, in a production
-environment.)
+Catalyst has a built-in http server for testing. (Later, you can easily
+use a more powerful server, e.g. Apache/mod_perl or FastCGI, in a
+production environment.)
Start your application on the command line...
Marcus Ramberg, C<mramberg@cpan.org>
Jesse Sheidlower, C<jester@panix.com>
Danijel Milicevic, C<me@danijel.de>
+Kieren Diment, C<kd@totaldatasolution.com>
+Yuval Kogman, C<nothingmuch@woobling.org>
=head1 COPYRIGHT
projects / catagits/Catalyst-Runtime.git / blobdiff