=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.
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
+available via C<< $self->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).
+
+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.
- my $model_name = $controller->{model_name};
+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 will get the right value. The C<config> accessor always only
-contains the original class configuration and must not be used for
-component configuration.
+For example:
+
+ package MyApp
+ use Moose;
-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.
+ 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
methods code. You can surround this by overriding the method in a
subclass:
- package Catalyst::Action::MyFoo;
+ package Catalyst::Action::MyFoo;
use Moose;
use namespace::autoclean;
- use MRO::Compat;
+ use MRO::Compat;
extends 'Catalyst::Action';
sub execute {
1;
We are using L<MRO::Compat> to ensure that you have the next::method
-call, from L<Class::C3> (in older perls), or natively (if you are using
-perl 5.10) to re-dispatch to the original C<execute> method in the
+call, from L<Class::C3> (in older perls), or natively (if you are using
+perl 5.10) to re-dispatch to the original C<execute> method in the
L<Catalyst::Action> class.
The Catalyst dispatcher handles an incoming request and, depending
-upon the dispatch type, will call the appropriate target or chain.
+upon the dispatch type, will call the appropriate target or chain.
From time to time it asks the actions themselves, or through the
controller, if they would match the current request. That's what the
C<match> method does. So by overriding this, you can change on what
For example, the action class below will make the action only match on
Mondays:
- package Catalyst::Action::OnlyMondays;
+ package Catalyst::Action::OnlyMondays;
use Moose;
use namespace::autoclean;
use MRO::Compat;
package MyApp::Controller::Foo;
use Moose;
use namespace::autoclean;
-
+
BEGIN { extends 'MyApp::Base::Controller::ModelBase'; }
__PACKAGE__->config( model_name => 'DB::Foo',
package Catalyst::View::MyView;
use Moose;
use namespace::autoclean;
-
+
extends 'Catalyst::View';
sub process {
if (!blessed($_[0]) || !$_[0]->isa('Catalyst::Action'));
return $uri;
};
-
+
Note that Catalyst will load any Moose Roles in the plugin list,
and apply them to your application class.
package CatalystX::Component::Foo;
use Moose;
use namespace::autoclean;
-
+
extends 'Catalyst::Component';
sub COMPONENT {
my $class = shift;
# Note: $app is like $c, but since the application isn't fully
- # initialized, we don't want to call it $c yet. $config
+ # initialized, we don't want to call it $c yet. $config
# is a hashref of config options possibly set on this component.
my ($app, $config) = @_;
projects / catagits/Catalyst-Manual.git / blobdiff