X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2F03_MoreCatalystBasics.pod;h=39d41bdb9856794dfd3b49104de44efde525ed58;hp=afddf454f62b04e9dbce4a3c97835ced15b9e876;hb=2217b252905d370f4f7840cf78996d43c79e5d4f;hpb=b9e431e31e8cbd4efc46e4270098567faf7e4f29

diff --git a/lib/Catalyst/Manual/Tutorial/03_MoreCatalystBasics.pod b/lib/Catalyst/Manual/Tutorial/03_MoreCatalystBasics.pod
index afddf45..39d41bd 100644
--- a/lib/Catalyst/Manual/Tutorial/03_MoreCatalystBasics.pod
+++ b/lib/Catalyst/Manual/Tutorial/03_MoreCatalystBasics.pod
@@ -66,7 +66,7 @@ all web applications.
 
 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
@@ -158,25 +158,25 @@ free to make use of it in your own projects.
 
 =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
@@ -192,7 +192,7 @@ formats:
 
 =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.
@@ -398,8 +398,8 @@ B<:Chained> -- Newer Catalyst applications tend to use the Chained
 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
@@ -428,9 +428,9 @@ L<HTML::Template> (L<http://html-template.sourceforge.net>).
 =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
@@ -698,12 +698,12 @@ L<Appendix 2|Catalyst::Manual::Tutorial::10_Appendices>.
 =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.
@@ -758,7 +758,7 @@ just installed into your Makefile.PL
 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 \
@@ -796,7 +796,7 @@ C<lib/MyApp/Schema.pm>.
 =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 *
@@ -807,7 +807,7 @@ SQLite.
 =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
@@ -848,7 +848,7 @@ can see these three model files listed in the debug output generated
 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
@@ -897,7 +897,7 @@ delete the next 2 lines):
 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.
 
@@ -912,8 +912,8 @@ Some other examples are provided in
 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
@@ -1131,7 +1131,7 @@ B<Notes:>
 
 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 *
@@ -1447,7 +1447,7 @@ information that can appear in that field (and can therefore inject
 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
@@ -1479,7 +1479,7 @@ if you wish.>
 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:
@@ -1506,9 +1506,9 @@ the controller does not define a controller-specific C<end> method, the
 =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 *
@@ -1518,7 +1518,7 @@ logic in C<RenderView>.  However, you can easily extend the
 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
@@ -1543,7 +1543,7 @@ Along with a summary of your application's state at the end of the
 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