X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FExtendingCatalyst.pod;h=3cc5967cae78d5e3216b1fd1fa825917a287978f;hb=512ec6d005f882e9f4502be3bfc9db2be2e7e1fd;hp=8b141d4111ab6061e6e56496b4c74b6cb2f4bb97;hpb=433f1ad4d6b7013515ccbe89062be0d3b0a60c27;p=catagits%2FCatalyst-Manual.git

diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod
index 8b141d4..3cc5967 100644
--- a/lib/Catalyst/Manual/ExtendingCatalyst.pod
+++ b/lib/Catalyst/Manual/ExtendingCatalyst.pod
@@ -115,7 +115,7 @@ L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>.
 =head2 Using Moose roles to apply method modifiers
 
 Rather than having a complex set of base classes which you have to mixin
-via multiple inheritence, if your functionality is well structured, then
+via multiple inheritance, 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.
 
@@ -238,43 +238,58 @@ array reference. As you can see, you can use attributes to configure
 your actions. You can specify or alter these attributes via
 L</"Component Configuration">, or even react on them as soon as
 Catalyst encounters them by providing your own L<component base
-class|/"Component Base Classes">.
+class|/"Component base classes">.
 
-=head2 Creating custom accessors
-
-L<Catalyst::Component> uses L<Class::Accessor::Fast> for accessor
-creation. Please refer to the modules documentation for usage
-information.
-
-=head2 Component configuration
+=head2 Component Configuration
 
 At creation time, the class configuration of your component (the one
 available via C<$self-E<gt>config>) will be merged with possible
 configuration settings from the applications configuration (either
-directly or via config file).  This is then stored in the controller
-object's hash reference. So, if you read possible configurations like:
+directly or via config file). This is done by Catalyst, and the
+correctly merged configuration is passed to your component's
+constructor (i.e. the new method).
 
-  my $model_name = $controller->{model_name};
+Ergo, if you define an accessor for each configuration value
+that your component takes, then the value will be automatically stored
+in the controller object's hash reference, and available from the
+accessor.
 
-you will get the right value. The C<config> accessor always only
-contains the original class configuration and must not be used for
-component configuration.
+The C<config> accessor always only contains the original class configuration
+and you B<MUST NEVER> call $self->config to get your component configuration,
+as the data there is likely to be a subset of the correct config.
 
-You are advised to create accessors on your component class for your
-configuration values. This is good practice and makes it easier to
-capture configuration key typos, or missing keys.
+For example:
+
+  package MyApp
+  use Moose;
+
+  extends 'Catalyst';
+
+  ...
 
-You can do this with L<Moose>:
+  __PACKAGE__->config(
+    'Controller::Foo' => { some_value => 'bar' },
+  );
+
+  ...
 
   package MyApp::Controller::Foo;
   use Moose;
   use namespace::autoclean;
   BEGIN { extends 'Catalyst::Controller' };
 
-  has model_name ( is => 'ro', required => 1 );
+  has some_value ( is => 'ro', required => 1 );
+
+  sub some_method {
+      my $self = shift;
+      return "the value of 'some_value' is " . $self->some_value;
+  }
 
   ...
-  my $model_name = $controller->model_name;
+
+  my $controller = $c->controller('Foo');
+  warn $controller->some_value;
+  warn $controller->some_method;
 
 =head1 IMPLEMENTATION