CatalystX::Declare::Keyword::Action - Declare Catalyst Actions
use CatalystX::Declare; controller MyApp::Web::Controller::Example { # chain base action with path part setting of '' # body-less actions don't do anything by themselves action base as '' under '/'; # simple end-point action action controller_class is final under base { $ctx->response->body( 'controller: ' . ref $self ); } # chain part actions can have arguments action str (Str $string) under base { $ctx->stash(chars => [split //, $string]); } # and end point actions too, of course action uc_chars (Int $count) under str is final { my $chars = $ctx->stash->{chars}; ... } # you can use a shortcut for multiple actions with # a common base under base { # this is an endpoint after base action normal is final; # the final keyword can be used to be more # visually explicit about end-points final action some_action { ... } # type dispatching works final action with_str (Str $x) as via_type; final action with_int (Int $x) as via_type; } # of course you can also chain to external actions final action some_end under '/some/controller/some/action'; }
This handler class provides the user with action, final and under keywords. There are multiple ways to define actions to allow for greater freedom of expression. While the parts of the action declaration itself do not care about their order, their syntax is rather strict.
action
final
under
You can choose to separate syntax elements via , if you think it is more readable. The action declaration
,
action foo is final under base;
is parsed in exactly the same way if you write it as
action foo, is final, under base;
The simplest possible declaration is
action foo;
This would define a chain-part action chained to nothing with the name foo and no arguments. Since it isn't followed by a block, the body of the action will be empty.
foo
You will automatically be provided with two variables: $self is, as you might expect, your controller instance. $ctx will be the Catalyst context object. Thus, the following code would stash the value returned by the get_item method:
$self
$ctx
get_item
action foo { $ctx->stash(item => $self->get_item); }
Some might ask why the context object is called $ctx instead of the usual $c. The reason is simple: It's an opinionated best practice, since $ctx stands out more.
$c
As usual with Catalyst actions, the path part (the public name of this part of the URI, if you're not familiar with the term yet) will default to the name of the action itself (or more correctly: to whatever Catalyst defaults).
To change that, use the as option:
as
under something { action base as ''; # <empty> action something as 'foo/bar'; # foo/bar action barely as bareword; # bareword }
Currently, CatalystX::Declare is completely based on the concept of chained actions. Every action you declare is chained or private. You can specify the action you want to chain to with the under option:
action foo; # chained to nothing action foo under '/'; # also chained to / action foo under bar; # chained to the local bar action action foo under '/bar/baz'; # chained to baz in /bar
under is also provided as a grouping keyword. Every action inside the block will be chained to the specified action:
under base { action foo { ... } action bar { ... } }
You can also use the under keyword for a single action. This is useful if you want to highlight a single action with a significant diversion from what is to be expected:
action base under '/'; under '/the/sink' is final action foo; final action bar under base; final action baz under base;
Instead of the under option declaration, you can also use a more english variant named chains to. While under might be nice and concise, some people might prefer this if they confuse under with the specification of a public path part. The argument to chains to is the same as to under:
chains to
action foo chains to bar; action foo under bar;
By default all actions are chain-parts, not end-points. If you want an action to be picked up as end-point and available via a public path, you have to say so explicitely by using the is final option:
is final
action base under '/'; action foo under base is final; # /base/foo
You can also drop the is part of the is final option if you want:
is
under base, final action foo { ... }
You can make end-points more visually distinct by using the final keyword instead of the option:
action base under '/'; final action foo under base; # /base/foo
And of course, the final, under and action keywords can be used in combination whenever needed:
action base as '' under '/'; under base { final action list; # /list action load; under load { final action view; # /list/load/view final action edit; # /list/load/edit } }
There is also one shorthand alternative for declaring chain targets. You can specify an action after a <- following the action name:
<-
action base under '/'; final action foo <- base; # /base/foo
You can use signatures like you are use to from MooseX::Method::Signatures to declare action parameters. The number of positinoal arguments will be used during dispatching as well as their types.
The signature follows the action name:
# /foo/*/*/* final action foo (Int $year, Int $month, Int $day);
If you are using the shorthand definition, the signature follows the chain target:
# /foo/* final action foo <- base ($x) under '/' { ... }
Parameters may be specified on chain-parts and end-points:
# /base/*/foo/* action base (Str $lang) under '/'; final action page (Int $page_num) under base;
Named parameters will be populated with the values in the query parameters:
# /view/17/?page=3 final action view (Int $id, Int :$page = 1) under '/';
If you specify a query parameter to be an ArrayRef, it will be specially handled. For one, it will match even if there is no such value in the parameters. Second, it will always be wrapped as an array reference.
ArrayRef
Your end-points can also take an unspecified amount of arguments by specifying an array as a variable:
# /find/some/deep/path/spec final action find (@path) under '/';
The signatures are now validated during dispatching-time, and an action with a non-matching signature (number of positional arguments and their types) will not be dispatched to. This means that
action base under '/' as ''; under base { final as double, action double_integer (Int $x) { $ctx->response->body( $x * 2 ); } final as double, action double_string (Str $x) { $ctx->response->body( $x x 2 ); } }
will return foofoo when called as /double/foo and 46 when called as /double/23.
foofoo
/double/foo
46
/double/23
Method modifiers can not only be applied to methods, but also to actions. There is no way yet to override the attributes of an already established action via modifiers. However, you can modify the method underlying the action.
The following code is an example role modifying the consuming controller's base action:
base
use CatalystX::Declare; controller_role MyApp::Web::ControllerRole::RichBase { before base (Object $ctx) { $ctx->stash(something => $ctx->model('Item')); } }
Note that you have to specify the $ctx argument yourself, since you are modifying a method, not an action.
Any controller having a base action (or method, for this purpose), can now consume the RichBase role declared above:
RichBase
use CatalystX::Declare; controller MyApp::Web::Controller::Foo with MyApp::Web::Controller::RichBase { action base as '' under '/'; action show, final under base { $ctx->response->body( $ctx->stash->{something}->render, ); } }
You can consume multiple action roles similarly to the way you do with the class or role keyword:
action user with LoggedIn with isSuperUser {}
Or
action User with (LoggedIn, isSuperUser) {}
Lastly, you can pass parameters to the underlying Catalyst::Action using a syntax that is similar to method traits:
action myaction with hasRole(opt1=>'val1', opt2=>'val2')
Where %opts is a hash that is used to populate $action->attributes in the same way you might have done the following in classic Catalyst
%opts
sub myaction :Action :Does(hasRole) :opt1(val1) :opt2(val2)
Here's a more detailed example:
action User with hasLogger(log_engine=>'STDOUT') with hasPermissions( role=>['Administrator', 'Member'], ) {}
Think of these are classic catalyst subroutine attributes on steriods. Unlike subroutine attributes, you can split and format your code across multiple lines and you can use deep and complex data structures such as HashRefs or ArrayRefs. Also, since the parameters are grouped syntactically within the with keyword this should improve readability of your code, since it will be more clear which parameters belong to with roles. This should give CatalystX::Declare greater compatibility with legacy Catalyst code but offer us a way forward from needing subroutine attributes, which suffer from significant drawbacks.
with
A few caveats and differences from method traits. First of all, unlike method traits, parameters are not passed to the Catalyst::Action constructor, but instead used to populate the attributes attribute, which is to preserve compatibility with how subroutine attributes work in classic Catalyst.
attributes
Additionally, since subroutines attributes supported a very limited syntax for supplying values, we follow the convention where parameter values are pushed onto an arrayref. In other words the following:
action User with hasLogger(engine=>'STDOUT')
would create the following data structure:
$action->attributes->{engine} = ['STDOUT']
The one exception is that if the value is an arrayref, those will be merged:
action User with Permissions(roles=>[qw/admin member/]) {} ## Creates: $action->attributes->{roles} = ['admin','member']
My feeling is that this gives better backward compatibility with classic sub attributes:
sub User :Action :Does(Permissions) :roles(admin) :roles(member)
However, I realize this method could lead to namespace collisions within the $action-attributes> attribute. For now this is an avoidable issue. In the future we may add a $action-trait_attributes> or similar attribute to the Catalyst::Action class in order to resolve this issue.
$action-
This option is even more experimental
You might want to create an action with a different class than the usual Catalyst::Action. A usual suspect here is Catalyst::Action::RenderView. You can use the isa option (did I mention it's experimental?) to specify what class to use:
isa
controller MyApp::Web::Controller::Root { $CLASS->config(namespace => ''); action end isa RenderView; }
The loaded class will be Mooseified, so we are able to apply essential roles.
This option is a bit less, but still pretty experimental
You can declare private actions with the is private trait:
is private
action end is private isa RenderView;
These methods are implementation details. Unless you are extending or developing CatalystX::Declare, you should not be concerned with them.
Object->parse (Object $ctx, Str :$modifier?, Int :$skipped_declarator = 0)
A hook that will be invoked by MooseX::Declare when this instance is called to handle syntax. It will parse the action declaration, prepare attributes and add the actions to the controller.
See "AUTHOR" in CatalystX::Declare for author information.
This program is free software; you can redistribute it and/or modify it under the same terms as perl itself.
To install CatalystX::Declare, copy and paste the appropriate command in to your terminal.
cpanm
cpanm CatalystX::Declare
CPAN shell
perl -MCPAN -e shell install CatalystX::Declare
For more information on module installation, please visit the detailed CPAN module installation guide.