=item *
-L<Catalyst::Manual::Intro|Catalyst::Manual::Intro>
+L<Catalyst::Manual::Intro>
=item *
-L<Catalyst::Manual::Tutorial|Catalyst::Manual::Tutorial>
+L<Catalyst::Manual::Tutorial>
=item *
-L<Catalyst::Manual::Actions|Catalyst::Manual::Actions>
+L<Catalyst::Manual::Actions>
=item *
-L<Catalyst::Manual::Cookbook|Catalyst::Manual::Cookbook>
+L<Catalyst::Manual::Cookbook>
=item *
-L<Catalyst::Manual::DevelopmentProcess|Catalyst::Manual::DevelopmentProcess>
+L<Catalyst::Manual::DevelopmentProcess>
=item *
-L<Catalyst::Manual::ExtendingCatalyst|Catalyst::Manual::ExtendingCatalyst>
+L<Catalyst::Manual::ExtendingCatalyst>
=item *
-L<Catalyst::Manual::Internals|Catalyst::Manual::Internals>
+L<Catalyst::Manual::Internals>
=item *
=back
-
=head2 Books
For additional information on Catalyst, there are currently two books available:
-
=over 4
=item *
then generate an HTML page, which Catalyst will send to the user's
browser, using whatever web server you've configured.
-How does this help you?
+=head3 How does this help you?
In many ways. Suppose you have a small catalog now, and you're using a
lightweight database such as SQLite, or maybe just a text file. But
my $self = shift;
my ( $controller, $c, $test ) = @_;
$c->stash->{what} = 'world';
- $self->NEXT::execute( @_ );
+ $self->next::method( @_ );
};
1;
This document provides you with a short overview of common caveats and
best practices to use L<Moose>-based classes within Catalyst.
-
=head1 THE CONTEXT CLASS
A Moose-ified version of the context class should look like this:
package MyApp;
-
use Moose;
use namespace::autoclean;
use Catalyst (
# method modifiers generally must be created after setup because otherwise they will
# conflict with plugin overrides
- after 'finalize' => sub{
+ after 'finalize' => sub {
my $c = shift;
$c->log->info( 'done!' );
}
-You should also be aware, that roles in C<< $c-E<gt>setup >> are applied
+You should also be aware that roles in C<< $c-E<gt>setup >> are applied
after the last plugin with all the benefits of using a single
L<with()|Moose/"with (@roles)"> statement in an ordinary L<Moose> class.
you to pass parameters to roles, or perform conflict resolution.
Conflict detection still works as expected.
-
=head2 ACCESSORS
Most of the request-specific attributes like C<$c-E<gt>stash>,
slightly limits the gains that could be had by wielding the full power
of L<Moose> attributes.
-Most of the accessors to information gathered during compile time is
-managed by C<Catalyst::ClassData>, which is a L<Moose>-aware version
-of L<Class::Data::Inheritable> but not compatible with
-L<MooseX::ClassAttribute>.
+Most of the accessors to information gathered during compile time (such
+as configuration) are managed by C<Catalyst::ClassData>, which is a
+L<Moose>-aware version of L<Class::Data::Inheritable> but not compatible
+with L<MooseX::ClassAttribute>.
=head2 ROLES AND METHOD MODIFIERS
If backward compatibility is of no concern to you, you could as easily
rewrite your plugins as roles and enjoy all the benefits of automatic
method re-dispatching of C<< before >> and C<< after >> method
-modifiers, naming conflict detecting and generally cleaner code.
+modifiers, naming conflict detection and generally cleaner code.
+
+=head3 NOTE
Plugins and roles should never use
after 'setup' => sub { ... } # wrong
-but rely on
+(or any other method of hooking the setup method) but rely on
after 'setup_finalize' => sub { ... } # this will work
=head1 CONTROLLERS
To activate Catalyst's action attributes, Moose-ified controller
-classes need to extend L<Catalyst::Controller> at compile time before
+classes need to extend L<Catalyst::Controller> at compile time, before
the actions themselves are declared:
package Catalyst::Controller::Root;
use namespace::autoclean;
BEGIN { extends 'Catalyst::Controller'; }
- with qw(
- # your controller roles
- );
-
+
=head2 Controller Roles
It is possible to use roles to apply method modifiers on controller actions
-from 5.80003 onwards, or use modifiers in actions in your controller classes
-themselves.
-
+from 5.80003 onwards, or use modifiers in your controller classes
+themselves. For example
+
+ package MyApp::Controller::Foo;
+ use Moose;
+ use namespace::autoclean;
+ BEGIN { extends 'Catalyst::Controller' };
+
+ sub foo : Local {
+ my ($self, $c) = @_;
+ $c->res->body('Hello ');
+ }
+ after foo => sub {
+ my ($self, $c) = @_;
+ $c->res->body($c->res->body . 'World');
+ };
+
It is possible to have action methods with attributes inside Moose roles, using
the trait introduced in L<MooseX::MethodAttributes> version 0.12, example:
...
}
+ package MyApp::Controller::Foo;
+ use Moose;
+ use namespace::autoclean;
+ BEGIN { extends 'Catalyst::Controller' };
+
+ with 'MyApp::ControllerRole';
+
+=head1 AUTHOR
+
+The Catalyst Core Team - see http://catalyst.perl.org/
+
+=head1 COPYRIGHT
+
+This program is free software. You can redistribute it and/or modify it
+under the same terms as Perl itself.
Catalyst::Manual::DevelopmentProcess - Administrative structure of the Catalyst Development Process
-=head1 Aims of the Catalyst Core Team
+=head1 Catalyst development
-The main current goals of the Catalyst core development team continue to
-be stability, performance, and a more paced addition of features, with a
-focus on extensibility.
+=head2 Schedule
+
+There is no dated release cycle for Catalyst. New releases will be made
+when sufficient small fixes have accumalated, or an important bugfix, or
+significant feature addition is completed.
-The Catalyst Roadmap at
+=head2 Roadmanp for features
+
+The Catalyst Roadmap is kept at
L<http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Runtime/5.80/trunk/lib/Roadmap.pod>
-will remain as is,
-and continues to reflect the specific priorities and schedule for future
-releases.
-=head1 Charter for the Catalyst Core Team
+=head2 Bug list
+
+The TODO list with known bugs / deficiences is kept at
+L<http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Runtime/5.80/trunk/TODO>
-=head2 Intention
+=head1 The Catalyst Core Team
The intention of the Catalyst Core Team is to maintain and support the
Catalyst framework, in order for it to be a viable and stable framework
decisions about the Catalyst core distribution, and public relations
relating to the Catalyst framework as a whole.
-The main priority for development is stability for the users of the
-framework, while improving usability and extensibility, as well as
-improving documentation and ease of deployment.
+The current goals of the Catalyst core development team are
+be stability, performance, and a paced addition of features, with a
+focus on extensibility.
+
+The core team are concerned with the 'core' Catalyst distributions
+(i.e. L<Catalyst::Runtime>, L<Catalyst::Devel> and L<Catalyst::Manual>),
+and also tries to encourage best practices for extension authors and
+cooperation and shared vision within the Catalyst community.
=head2 Membership
The Catalyst Core Team consists of the developers that have full commit
-privileges to the entire Catalyst source tree.
+privileges to the entire Catalyst source tree, who have made a significant
+contribution to the core Catalyst distributions, and various extensions and
+pugins.
-In addition, the core team may accept members that have non-technical
+In addition, the core team includes members that have non-technical
roles such as marketing, legal, or economic responsibilities.
Currently, the Core Team consists of the following people:
questions or other correspondence. In cases where this is not possible,
the same order as for CPAN Releases applies.
+=head1 Contributing to Catalyst
+
+The main philosophy behind Catalyst development can be surimsed as:
+
+ Patches welcome!
+
+Everyone is welcome (and will be encouraged) to contribute to Catalyst
+in whatever capacity they're able to. People in #catalyst-dev will be
+more than happy to talk newcomers through contributing their first patch,
+or how best to go about their first CPAN extension module..
+
+=head2 Repositories
+
+The Catalyst subversion repository can be found at:
+
+ http://dev.catalyst.perl.org/repos/Catalyst
+
+and the git repository can be found at FIXME
+
+=head2 New Catalyst extensions
+
+As Catalyst is deliberately designed for extension, there is an ecosystem of
+several hundred Catalyst extensions which can be found on CPAN.
+FIXME
projects / catagits/Catalyst-Manual.git / commitdiff