You can check out the source code for this example from the Catalyst
Subversion repository as per the instructions in
-L<Catalyst::Manual::Tutorial::01_Intro|Catalyst::Manual::Tutorial::01_Intro>.
+L<Catalyst::Manual::Tutorial::01_Intro>.
Please take a look at
L<Catalyst::Manual::Tutorial::01_Intro/CATALYST INSTALLATION> before
=item *
-L<Catalyst::Plugin::ConfigLoader|Catalyst::Plugin::ConfigLoader>
+L<Catalyst::Plugin::ConfigLoader>
C<ConfigLoader> provides an automatic way to load configurable
parameters for your application from a central
-L<Config::General|Config::General> file (versus having the values
+L<Config::General> file (versus having the values
hard-coded inside your Perl modules). Config::General uses syntax very
similar to Apache configuration files. We will see how to use this
feature of Catalyst during the authentication and authorization sections
(Chapter 5 and Chapter 6).
B<IMPORTANT NOTE:> If you are using a version of
-L<Catalyst::Devel|Catalyst::Devel> prior to version 1.06, be aware that
+L<Catalyst::Devel> prior to version 1.06, be aware that
Catalyst changed the default format from YAML to the more
straightforward C<Config::General> style. This tutorial uses the newer
C<myapp.conf> file for C<Config::General>. However, Catalyst supports
both formats and will automatically use either C<myapp.conf> or
C<myapp.yml> (or any other format supported by
-L<Catalyst::Plugin::ConfigLoader|Catalyst::Plugin::ConfigLoader> and
-L<Config::Any|Config::Any>). If you are using a version of
+L<Catalyst::Plugin::ConfigLoader> and
+L<Config::Any>). If you are using a version of
Catalyst::Devel prior to 1.06, you can convert to the newer format by
simply creating the C<myapp.conf> file manually and deleting
C<myapp.yml>. The default contents of the C<myapp.conf> you create
=item *
-L<Catalyst::Plugin::Static::Simple|Catalyst::Plugin::Static::Simple>
+L<Catalyst::Plugin::Static::Simple>
C<Static::Simple> provides an easy way to serve static content, such as
images and CSS files, from the development server.
dispatch form of action types because of its power and flexibility. It
allows a series of controller methods to be automatically dispatched to
service a single user request. See
-L<Catalyst::Manual::Tutorial::04_BasicCRUD|Catalyst::Manual::Tutorial::04_BasicCRUD>
-and L<Catalyst::DispatchType::Chained|Catalyst::DispatchType::Chained>
+L<Catalyst::Manual::Tutorial::04_BasicCRUD>
+and L<Catalyst::DispatchType::Chained>
for more information on chained actions.
=back
=head2 Create a Catalyst View
When using TT for the Catalyst view, the main helper script is
-L<Catalyst::Helper::View::TT|Catalyst::Helper::View::TT>. You may also
+L<Catalyst::Helper::View::TT>. You may also
come across references to
-L<Catalyst::Helper::View::TTSite|Catalyst::Helper::View::TTSite>, but
+L<Catalyst::Helper::View::TTSite>, but
its use is now deprecated.
Enter the following command to enable the C<TT> style of view rendering
=head1 DATABASE ACCESS WITH DBIx::Class
Catalyst can be used with virtually any form of datastore available via
-Perl. For example, L<Catalyst::Model::DBI|Catalyst::Model::DBI> can be
+Perl. For example, L<Catalyst::Model::DBI> can be
used to access databases through the traditional Perl L<DBI> interface
or you can use a model to access files of any type on the filesystem.
However, most Catalyst applications use some form of object-relational
mapping (ORM) technology to create objects associated with tables in a
-relational database. Matt Trout's L<DBIx::Class|DBIx::Class>
+relational database. Matt Trout's L<DBIx::Class>
(abbreviated as "DBIC") has rapidly emerged as the Perl-based ORM
technology of choice. Most new Catalyst applications rely on
DBIx::Class, as will this tutorial.
Before you continue, make sure your C<myapp.db> database file is in the
application's topmost directory. Now use the model helper with the
C<create=static> option to read the database with
-L<DBIx::Class::Schema::Loader|DBIx::Class::Schema::Loader> and
+L<DBIx::Class::Schema::Loader> and
automatically build the required files for us:
$ script/myapp_create.pl model DB DBIC::Schema MyApp::Schema \
=item *
C<create=static> causes
-L<DBIx::Class::Schema::Loader|DBIx::Class::Schema::Loader> to load the
+L<DBIx::Class::Schema::Loader> to load the
schema as it runs and then write that information out into files.
=item *
=item *
And finally, the C<on_connect_do> string requests that
-L<DBIx::Class::Schema::Loader|DBIx::Class::Schema::Loader> create
+L<DBIx::Class::Schema::Loader> create
foreign key relationships for us (this is not needed for databases such
as PostgreSQL and MySQL, but is required for SQLite). If you take a look
at C<lib/MyApp/Model/DB.pm>, you will see that the SQLite pragma is
when you launch the application).
B<NOTE:> Older versions of
-L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema> use the
+L<Catalyst::Model::DBIC::Schema> use the
deprecated DBIx::Class C<load_classes> technique instead of the newer
C<load_namespaces>. For new applications, please try to use
C<load_namespaces> since it more easily supports a very useful DBIC
B<TIP>: You may see the C<$c-E<gt>model('DB::Book')> un-commented above
written as C<$c-E<gt>model('DB')-E<gt>resultset('Book')>. The two are
equivalent. Either way, C<$c-E<gt>model> returns a
-L<DBIx::Class::ResultSet|DBIx::Class::ResultSet> which handles queries
+L<DBIx::Class::ResultSet> which handles queries
against the database and iterating over the set of results that is
returned.
L<DBIx::Class::Manual::Cookbook/Complex WHERE clauses>, with additional
information found at L<DBIx::Class::ResultSet/search>,
L<DBIx::Class::Manual::FAQ/Searching>,
-L<DBIx::Class::Manual::Intro|DBIx::Class::Manual::Intro> and
-L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema>.
+L<DBIx::Class::Manual::Intro> and
+L<Catalyst::Model::DBIC::Schema>.
=head2 Test Run The Application
The Catalyst stash only lasts for a single HTTP request. If you need to
retain information across requests you can use
-L<Catalyst::Plugin::Session|Catalyst::Plugin::Session> (we will use
+L<Catalyst::Plugin::Session> (we will use
Catalyst sessions in the Authentication chapter of the tutorial).
=item *
markup or code if you don't "neutralize" those fields). In addition to
"| html", Template Toolkit has a variety of other useful filters that
can found in the documentation for
-L<Template::Filters|Template::Filters>.
+L<Template::Filters>.
=head1 RUNNING THE APPLICATION FROM THE COMMAND LINE
Once your controller logic has processed the request from a user, it
forwards processing to your view in order to generate the appropriate
response output. Catalyst uses
-L<Catalyst::Action::RenderView|Catalyst::Action::RenderView> by default
+L<Catalyst::Action::RenderView> by default
to automatically perform this operation. If you look in
C<lib/MyApp/Controller/Root.pm>, you should see the empty definition for
the C<sub end> method:
=item *
Because the definition includes an C<ActionClass> attribute, the
-L<Catalyst::Action::RenderView|Catalyst::Action::RenderView> logic will
+L<Catalyst::Action::RenderView> logic will
be executed B<after> any code inside the definition of C<sub end> is
-run. See L<Catalyst::Manual::Actions|Catalyst::Manual::Actions> for
+run. See L<Catalyst::Manual::Actions> for
more information on C<ActionClass>.
=item *
C<RenderView> logic by adding your own code inside the empty method body
(C<{}>) created by the Catalyst Helpers when we first ran the
C<catalyst.pl> to initialize our application. See
-L<Catalyst::Action::RenderView|Catalyst::Action::RenderView> for more
+L<Catalyst::Action::RenderView> for more
detailed information on how to extend C<RenderView> in C<sub end>.
=back
processing for that request. The "Stash" section should show a
summarized version of the DBIC book model objects. If desired, you can
adjust the summarization logic (called "scrubbing" logic) -- see
-L<Catalyst::Action::RenderView|Catalyst::Action::RenderView> for
+L<Catalyst::Action::RenderView> for
details.
Note that you shouldn't need to worry about "normal clients" using this
projects / catagits/Catalyst-Manual.git / blobdiff