X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FExtendingCatalyst.pod;h=e2e81d0abb77fc65c40d06879718acca3dbfc5f0;hb=2a1309e65f1a25053712bccb3b4fb8e63d05f281;hp=97c31b66f271d7e2c4565d644609ca7ba5fe5063;hpb=7ce05098c9b1df9078e709e5a724e821a3b3b00d;p=catagits%2FCatalyst-Manual.git
diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod
index 97c31b6..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:
@@ -243,7 +244,7 @@ class|/"Component base classes">.
=head2 Component Configuration
At creation time, the class configuration of your component (the one
-available via C<$self-Econfig>) 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 +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
@@ -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
-
-