Release commit for 5.9013

[catagits/Catalyst-Manual.git] / lib / Catalyst / Manual / ExtendingCatalyst.pod

diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod
index 73af1bd..e2e81d0 100644 (file)
--- a/lib/Catalyst/Manual/ExtendingCatalyst.pod
+++ b/lib/Catalyst/Manual/ExtendingCatalyst.pod
@@ -14,7 +14,7 @@ Catalyst's behaviour, and this can be confusing. This document is
 written to help you understand the possibilities, current practices
 and their consequences.
 
-Please read the L<BEST PRACTICES> section before deciding on a design,
+Please read the L</BEST PRACTICES> section before deciding on a design,
 especially if you plan to release your code to CPAN. The Catalyst
 developer and user communities, which B<you are part of>, will benefit
 most if we all work together and coordinate.
@@ -68,7 +68,8 @@ there's always the IRC channel and the mailing list to discuss things.
 
 This gives a stable basis for contribution, and even more importantly,
 builds trust. The easiest way is a test application. See
-L<Catalyst::Manual::Tutorial::Testing> for more information.
+L<Catalyst::Manual::Tutorial::Testing|Catalyst::Manual::Tutorial::08_Testing>
+for more information.
 
 =back
 
@@ -102,7 +103,7 @@ try to load them as components.
 Writing a generic component that only works with Catalyst is wasteful
 of your time.  Try writing a plain perl module, and then a small bit
 of glue that integrates it with Catalyst.  See
-L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema> for a
+L<Catalyst::Model::DBIC::Schema> for a
 module that takes the approach.  The advantage here is that your
 "Catalyst" DBIC schema works perfectly outside of Catalyst, making
 testing (and command-line scripts) a breeze.  The actual Catalyst
@@ -110,7 +111,7 @@ Model is just a few lines of glue that makes working with the schema
 convenient.
 
 If you want the thinnest interface possible, take a look at
-L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>.
+L<Catalyst::Model::Adaptor>.
 
 =head2 Using Moose roles to apply method modifiers
 
@@ -160,7 +161,7 @@ your module to become a recommended addition, these things will prove
 invaluable.
 
 If you're just getting started, try using
-L<CatalystX::Starter|CatalystX::Starter> to generate some example
+L<CatalystX::Starter> to generate some example
 tests for your module.
 
 =head2 Maintenance
@@ -223,7 +224,7 @@ configuration. There is of course again more than one way to do it.
 
 You can specify any valid Perl attribute on Catalyst actions you like.
 (See L<attributes/"Syntax of Attribute Lists"> for a description of
-what is valid.) These will be available on the C<Catalyst::Action>
+what is valid.) These will be available on the L<Catalyst::Action>
 instance via its C<attributes> accessor. To give an example, this
 action:
 
@@ -255,7 +256,7 @@ in the controller object's hash reference, and available from the
 accessor.
 
 The C<config> accessor always only contains the original class configuration
-and you B<MUST NEVER> call $self->config to get your component configuration,
+and you B<MUST NEVER> call C<< $self->config >> to get your component configuration,
 as the data there is likely to be a subset of the correct config.
 
 For example:
@@ -580,7 +581,7 @@ lifecycle. If your functionality needs to change some C<prepare_*> or
 C<finalize_*> stages, you won't get around a plugin.
 
 Note, if you just want to hook into such a stage, and run code before,
-or after it, then it is recommended that you use L<Moose>s method modifiers
+or after it, then it is recommended that you use L<Moose>'s method modifiers
 to do this.
 
 Another valid target for a plugin architecture are things that
@@ -727,5 +728,3 @@ This library is free software. You can redistribute it and/or modify it under
 the same terms as Perl itself.
 
 =cut
-
-