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=3cc5967cae78d5e3216b1fd1fa825917a287978f;hp=56e237a37f3044597d063631fb7eebbd4f1495b8;hb=4307eb1cd503012fb2ff86ecd1d0da6b7f5b3d25;hpb=bbddff000787154dd9130f45634da8ef06529d86 diff --git a/lib/Catalyst/Manual/ExtendingCatalyst.pod b/lib/Catalyst/Manual/ExtendingCatalyst.pod index 56e237a..3cc5967 100644 --- a/lib/Catalyst/Manual/ExtendingCatalyst.pod +++ b/lib/Catalyst/Manual/ExtendingCatalyst.pod @@ -115,7 +115,7 @@ L. =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 roles, and method modifiers to hook onto to provide functionality. @@ -127,7 +127,7 @@ for more information about roles in general. =head2 Inheritance and overriding methods -When overriding a method, keep in mind that some day additionall +When overriding a method, keep in mind that some day additional 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 invocant off of C<@_> and assign the rest of the used arguments, so @@ -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, or even react on them as soon as Catalyst encounters them by providing your own L. +class|/"Component base classes">. -=head2 Creating custom accessors - -L uses L 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-Econfig>) 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 accessor always only -contains the original class configuration and must not be used for -component configuration. +The C accessor always only contains the original class configuration +and you B 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: + __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