[Catalyst-commits] r9966 - Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual

[t0m at dev.catalyst.perl.org]

Author: t0m
Date: 2009-04-30 20:18:45 +0100 (Thu, 30 Apr 2009)
New Revision: 9966

Modified:
   Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/ExtendingCatalyst.pod
Log:
Updates to ExtendingCatalyst, more to come

Modified: Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/ExtendingCatalyst.pod
===================================================================
--- Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/ExtendingCatalyst.pod	2009-04-30 18:12:49 UTC (rev 9965)
+++ Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/ExtendingCatalyst.pod	2009-04-30 19:18:45 UTC (rev 9966)
@@ -56,7 +56,8 @@
 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<Moose::Role>
+Also, if you think you really need a plugin, please instead consider
+using a L<Moose::Role>.
 
 =item There's a community. Use it!
 
@@ -77,6 +78,9 @@
 in the C<Catalyst::*> namespace, the Catalyst core would like to ask
 developers to use the C<CatalystX::*> namespace if possible.
 
+Please B<do not> invent components which are outside the well
+known C<Model>, C<View>, C<Controller> or C<Plugin> namespaces!
+
 When you try to put a base class for a C<Model>, C<View> or
 C<Controller> directly under your C<MyApp> directory as, for example,
 C<MyApp::Controller::Foo>, you will have the problem that Catalyst
@@ -113,20 +117,12 @@
 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<Moose> roles, and method modifiers
-to hook onto to provide functionality. 
+to hook onto to provide functionality.
 
 For a simple example of this, see L<CatalystX::REPL>.
 
-B<Note:> 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<NEXT> (for multiple
-inheritance), extension developers are encouraged to use L<Class::C3>,
-via L<MRO::Compat>, 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 @@
 
   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 @@
     $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 @@
 class' C<new> method to return the component object.
 
 You can override this method and do and return whatever you want.
-However, you should use L<Class::C3> (via L<MRO::Compat>) to forward 
-to the original C<COMPONENT> method to merge the configuration of 
+However, you should use L<Class::C3> (via L<MRO::Compat>) to forward
+to the original C<COMPONENT> method to merge the configuration of
 your component.
 
 Here is a stub C<COMPONENT> method:
@@ -644,7 +642,8 @@
 component or really do anything compatible with Catalyst's
 expectations on a component.
 
-For more information, please see L<Catalyst::Component/"COMPONENT($c,$arguments)">.
+For more information, please see
+L<Catalyst::Component/"COMPONENT($c,$arguments)">.
 
 =head1 SEE ALSO