=head1 EXAMPLE ACTIONS
-=head2 Catalyst::Action::RenderView
+=head2 L<Catalyst::Action::RenderView>
This is meant to decorate end actions. It's similar in operation to
L<Catalyst::Plugin::DefaultEnd>, but allows you to decide on an action
level rather than on an application level where it should be run.
-=head2 Catalyst::Action::REST
+=head2 L<Catalyst::Action::REST>
Provides additional syntax for dispatching based upon the HTTP method
of the request.
=head1 EXAMPLE ACTIONROLES
-=head2 Catalyst::ActionRole::ACL
+=head2 L<Catalyst::ActionRole::ACL>
Provides ACLs for role membership by decorating your actions.
of L<Moose> attributes.
Most of the accessors to information gathered during compile time (such
-as configuration) are managed by C<Catalyst::ClassData>, which is a
+as configuration) are managed by L<Catalyst::ClassData>, which is a
L<Moose>-aware version of L<Class::Data::Inheritable> but not compatible
with L<MooseX::ClassAttribute>.
=head2 L<Catalyst::Controller::HTML::FormFu>
-Catalyst integration for <HTML::FormFu>.
+Catalyst integration for L<HTML::FormFu>.
=head1 MODELS
=head2 L<Catalyst::Model::CDBI>
-The C<Class::DBI> (CDBI) model class. It is built on top of
-C<Class::DBI::Loader>, which automates the definition of C<Class::DBI>
+The L<Class::DBI> (CDBI) model class. It is built on top of
+L<Class::DBI::Loader>, which automates the definition of L<Class::DBI>
sub-classes by scanning the underlying table schemas, setting up columns
and primary keys.
=head2 L<Catalyst::Model::CDBI::Plain>
-A neutral interface to the C<Class::DBI> module which does not attempt
+A neutral interface to the L<Class::DBI> module which does not attempt
to automate table setup. It allows the user to manually set up
-C<Class::DBI> classes, either by doing so within the Catalyst model
-classes themselves, or by inheriting from existing C<Class::DBI>
+L<Class::DBI> classes, either by doing so within the Catalyst model
+classes themselves, or by inheriting from existing L<Class::DBI>
classes.
=head2 L<Catalyst::Model::DBIC::Schema>
two. The second line tests and loads our application in test mode. The
fourth line verifies that our application returns a successful response.
-C<Catalyst::Test> exports two functions, C<request> and C<get>. Each can
+L<Catalyst::Test> exports two functions, C<request> and C<get>. Each can
take three different arguments:
=over 4
request('/my/path');
request('http://www.host.com/my/path');
-=item An instance of C<URI>.
+=item An instance of L<URI>.
request( URI->new('http://www.host.com/my/path') );
-=item An instance of C<HTTP::Request>.
+=item An instance of L<HTTP::Request>.
request( HTTP::Request->new( GET => 'http://www.host.com/my/path') );
=back
-C<request> returns an instance of C<HTTP::Response> and C<get> returns the
+C<request> returns an instance of L<HTTP::Response> and C<get> returns the
content (body) of the response.
=head3 Running tests locally
your application. In C<CGI> or C<FastCGI> it should be the host and path
to the script.
-=head3 C<Test::WWW::Mechanize> and Catalyst
+=head3 L<Test::WWW::Mechanize> and Catalyst
-Be sure to check out C<Test::WWW::Mechanize::Catalyst>. It makes it easy to
+Be sure to check out L<Test::WWW::Mechanize::Catalyst>. It makes it easy to
test HTML, forms and links. A short example of usage:
use Test::More tests => 6;
Parameters passed in the URL query string are handled with methods in
the L<Catalyst::Request> class. The C<param> method is functionally
-equivalent to the C<param> method of C<CGI.pm> and can be used in
+equivalent to the C<param> method of L<CGI.pm|CGI> and can be used in
modules that require this.
# http://localhost:3000/catalog/view/?category=hardware&page=3
If you would prefer to install directly from CPAN and not use the
Tutorial Virtual machine, you can download the example program and all
the necessary dependencies to your local machine by installing the
-C<Task::Catalyst::Tutorial> distribution:
+L<Task::Catalyst::Tutorial> distribution:
cpan Task::Catalyst::Tutorial
$ script/hello_create.pl view HTML TT
This creates the F<lib/Hello/View/HTML.pm> module, which is a subclass
-of C<Catalyst::View::TT>.
+of L<Catalyst::View::TT>.
=over 4
Now that the HTML.pm "View" exists, Catalyst will autodiscover it and be
able to use it to display the view templates using the "process" method
-that it inherits from the C<Catalyst::View::TT> class.
+that it inherits from the L<Catalyst::View::TT> class.
Template Toolkit is a very full-featured template facility, with
excellent documentation at L<http://template-toolkit.org/>, but since
=head2 Create Static DBIx::Class Schema Files
B<Note:> If you are not following along in the Tutorial Virtual Machine,
-please be sure that you have version 1.27 or higher of DBD::SQLite and
-version 0.39 or higher of Catalyst::Model::DBIC::Schema. (The Tutorial
+please be sure that you have version 1.27 or higher of L<DBD::SQLite> and
+version 0.39 or higher of L<Catalyst::Model::DBIC::Schema>. (The Tutorial
VM already has versions that are known to work.) You can get your
currently installed version numbers with the following commands.
=head2 Create a ResultSet Class
An often overlooked but extremely powerful features of DBIC is that it
-allows you to supply your own subclasses of C<DBIx::Class::ResultSet>.
+allows you to supply your own subclasses of L<DBIx::Class::ResultSet>.
This can be used to pull complex and unsightly "query code" out of your
controllers and encapsulate it in a method of your ResultSet Class.
These "canned queries" in your ResultSet Class can then be invoked via a
=head2 Chaining ResultSets
-One of the most helpful and powerful features in C<DBIx::Class> is that
+One of the most helpful and powerful features in L<DBIx::Class> is that
it allows you to "chain together" a series of queries (note that this
has nothing to do with the "Chained Dispatch" for Catalyst that we were
discussing earlier). Because each ResultSet method returns another
=head2 Create a Form Config File
-Although C<HTML::FormFu> supports any configuration file handled by
+Although L<HTML::FormFu> supports any configuration file handled by
L<Config::Any>, most people tend to use YAML. First create a directory
to hold your form configuration files:
=item *
-The Perl C<DBD::MySQL> module
+The Perl L<DBD::MySQL> module
=back
projects / catagits/Catalyst-Manual.git / commitdiff