X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FExtendingCatalyst.pod;h=5aa74c1bf4487df4c6c5c68176ce6e3a85cafca1;hp=97c31b66f271d7e2c4565d644609ca7ba5fe5063;hb=388f66e0214312ffa77b48128d2fa2e1932b4669;hpb=7ce05098c9b1df9078e709e5a724e821a3b3b00d

diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod
index 97c31b6..5aa74c1 100644
--- 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.
@@ -102,7 +102,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 +110,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 +160,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
@@ -243,7 +243,7 @@ class|/"Component base classes">.
 =head2 Component Configuration
 
 At creation time, the class configuration of your component (the one
-available via C<$self-E<gt>config>) will be merged with possible
+available via C<< $self->config >>) will be merged with possible
 configuration settings from the applications configuration (either
 directly or via config file). This is done by Catalyst, and the
 correctly merged configuration is passed to your component's
@@ -255,7 +255,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 +580,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 +727,3 @@ This library is free software. You can redistribute it and/or modify it under
 the same terms as Perl itself.
 
 =cut
-
-