X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FExtendingCatalyst.pod;h=e2e81d0abb77fc65c40d06879718acca3dbfc5f0;hb=e454845a14b3930af0f7ba679f61e43bb05528b5;hp=9f73e8d13044d313c634e7a65e6d85afc31fcc37;hpb=f9ce297698249b24617c5a60e7c625f2005be144;p=catagits%2FCatalyst-Manual.git
diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod
index 9f73e8d..e2e81d0 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 section before deciding on a design,
+Please read the L section before deciding on a design,
especially if you plan to release your code to CPAN. The Catalyst
developer and user communities, which B, 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 for more information.
+L
+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 for a
+L 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.
+L.
=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 to generate some example
+L 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 for a description of
-what is valid.) These will be available on the C
+what is valid.) These will be available on the L
instance via its C 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 accessor always only contains the original class configuration
-and you B call $self->config to get your component configuration,
+and you B 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 or
C 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 Ls method modifiers
+or after it, then it is recommended that you use L's method modifiers
to do this.
Another valid target for a plugin architecture are things that