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=1d5b6ec581f7ee55667e19a3746a7369e85ea071;hb=388f66e0214312ffa77b48128d2fa2e1932b4669;hpb=080bb6202ae1dc9a786bb32afcb391f542c2f0fc diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod index 1d5b6ec..5aa74c1 100644 --- a/lib/Catalyst/Manual/ExtendingCatalyst.pod +++ b/lib/Catalyst/Manual/ExtendingCatalyst.pod @@ -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 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 +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. +L. =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 to generate some example +L to generate some example tests for your module. =head2 Maintenance