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=2e497f14390d96e51a9e67adf09ec7d0f7dcdaa8;hp=dc88b5201dea996b5f66bd47b829f24554fa29aa;hb=fa025310d03b9a7c3da9368c6cd7aec3ced82820;hpb=845ef40515e6cfbdfb8c6b53a5872fb216225feb diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod index dc88b52..2e497f1 100644 --- a/lib/Catalyst/Manual/ExtendingCatalyst.pod +++ b/lib/Catalyst/Manual/ExtendingCatalyst.pod @@ -56,7 +56,8 @@ A plugin should be careful since it's overriding Catalyst internals. If your plugin doesn't really need to muck with the internals, make it a base Controller or Model. -If you need to hook (but not alter) the internals, then make it a L +Also, if you think you really need a plugin, please instead consider +using a L. =item There's a community. Use it! @@ -77,6 +78,9 @@ While some core extensions (engines, plugins, etc.) have to be placed in the C namespace, the Catalyst core would like to ask developers to use the C namespace if possible. +Please B invent components which are outside the well +known C, C, C or C namespaces! + When you try to put a base class for a C, C or C directly under your C directory as, for example, C, you will have the problem that Catalyst @@ -113,20 +117,12 @@ L. Rather than having a complex set of base classes which you have to mixin via multiple inheritence, if your functionality is well structured, then it's possible to use the composability of L roles, and method modifiers -to hook onto to provide functionality. +to hook onto to provide functionality. For a simple example of this, see L. -B Currently, controllers with attributes will not function correctly -in conjunction with Moose roles. - =head2 Inheritance and overriding methods -While Catalyst itself is still based on L (for multiple -inheritance), extension developers are encouraged to use L, -via L, which is what Catalyst will be switching to in the -5.80 release. - When overriding a method, keep in mind that some day additionally arguments may be provided to the method, if the last parameter is not a flat list. It is thus better to override a method by shifting the @@ -135,9 +131,11 @@ you can pass your complete arguments to the original method via C<@_>: use MRO::Compat; ... - sub foo { my $self = shift; - my ($bar, $baz) = @_; # ... return - $self->next::method(@_); } + sub foo { + my $self = shift; + my ($bar, $baz) = @_; # ... return + $self->next::method(@_); + } If you would do the common @@ -602,7 +600,7 @@ A simple example like this is actually better as a L role, for example: $c->log->warn( 'uri_for with non action: ', join(', ', @_), ) if (!blessed($_[0]) || !$_[0]->isa('Catalyst::Action')); return $uri; - }; + }; =head2 Factory components with COMPONENT() @@ -614,8 +612,8 @@ Curation with the application wide overrides and call the class' C method to return the component object. You can override this method and do and return whatever you want. -However, you should use L (via L) to forward -to the original C method to merge the configuration of +However, you should use L (via L) to forward +to the original C method to merge the configuration of your component. Here is a stub C method: @@ -644,7 +642,8 @@ You are free to re-bless the object, instantiate a whole other component or really do anything compatible with Catalyst's expectations on a component. -For more information, please see L. +For more information, please see +L. =head1 SEE ALSO