- NAME
- SYNOPSIS
- DESCRIPTION
- METHODS
- USAGE
- AUTHOR
NAME
Catalyst::DispatchType::Chained - Path Part DispatchType
SYNOPSIS
# root action - captures one argument after it sub foo_setup : Chained('/') PathPart('foo') CaptureArgs(1) { my ( $self, $c, $foo_arg ) = @_; ... } # child action endpoint - takes one argument sub bar : Chained('foo_setup') Args(1) { my ( $self, $c, $bar_arg ) = @_; ... }
DESCRIPTION
METHODS
$self->list($c)
Debug output for Path Part dispatch points
$self->match( $c, $path )
Calls
recurse_match to see if a chain matches the
$path.
$self->recurse_match( $c, $parent, \@path_parts )
Recursive search for a matching chain.
$self->register( $c, $action )
Calls register_path for every Path attribute for the given $action.
$self->uri_for_action($action, $captures)
Get the URI part for the action, using
$captures to fill the capturing parts.
USAGE
Introduction
The
Chained attribute allows you to chain public path parts together by their private names. A chain part's path can be specified with
PathPart and can be declared to expect an arbitrary number of arguments. The endpoint of the chain specifies how many arguments it gets through the
Args attribute.
:Args(0) would be none at all,
:Args without an integer would be unlimited. The path parts that aren't endpoints are using
CaptureArgs to specify how many parameters they expect to receive. As an example setup:
package MyApp::Controller::Greeting; use base qw/ Catalyst::Controller /; # this is the beginning of our chain sub hello : PathPart('hello') Chained('/') CaptureArgs(1) { my ( $self, $c, $integer ) = @_; $c->stash->{ message } = "Hello "; $c->stash->{ arg_sum } = $integer; } # this is our endpoint, because it has no :CaptureArgs sub world : PathPart('world') Chained('hello') Args(1) { my ( $self, $c, $integer ) = @_; $c->stash->{ message } .= "World!"; $c->stash->{ arg_sum } += $integer; $c->response->body( join "<br/>\n" => $c->stash->{ message }, $c->stash->{ arg_sum } ); }
The debug output provides a separate table for chained actions, showing the whole chain as it would match and the actions it contains. Here's an example of the startup output with our actions above:
... [debug] Loaded Path Part actions: .-----------------------+------------------------------. | Path Spec | Private | +-----------------------+------------------------------+ | /hello/*/world/* | /greeting/hello (1) | | | => /greeting/world | '-----------------------+------------------------------' ...
As you can see, Catalyst only deals with chains as whole paths and builds one for each endpoint, which are the actions with
:Chained but without
:CaptureArgs.
Let's assume this application gets a request at the path
/hello/23/world/12. What happens then? First, Catalyst will dispatch to the
hello action and pass the value
23 as an argument to it after the context. It does so because we have previously used
:CaptureArgs(1) to declare that it has one path part after itself as its argument. We told Catalyst that this is the beginning of the chain by specifying
:Chained('/'). Also note that instead of saying
:PathPart('hello') we could also just have said
:PathPart, as it defaults to the name of the action.
After
hello has run, Catalyst goes on to dispatch to the
world action. This is the last action to be called: Catalyst knows this is an endpoint because we did not specify a
:CaptureArgs attribute. Nevertheless we specify that this action expects an argument, but at this point we're using
:Args(1) to do that. We could also have said
:Args or left it out altogether, which would mean this action would get all arguments that are there. This action's
:Chained attribute says
hello and tells Catalyst that the
hello action in the current controller is its parent.
With this we have built a chain consisting of two public path parts.
hello captures one part of the path as its argument, and also specifies the path root as its parent. So this part is
/hello/$arg. The next part is the endpoint
world, expecting one argument. It sums up to the path part
world/$arg. This leads to a complete chain of
/hello/$arg/world/$arg which is matched against the requested paths.
This example application would, if run and called by e.g.
/hello/23/world/12, set the stash value
message to "Hello" and the value
arg_sum to "23". The
world action would then append "World!" to
message and add
12 to the stash's
arg_sum value. For the sake of simplicity no view is shown. Instead we just put the values of the stash into our body. So the output would look like:
Hello World! 35
And our test server would have given us this debugging output for the request:
... [debug] "GET" request for "hello/23/world/12" from "127.0.0.1" [debug] Path is "/greeting/world" [debug] Arguments are "12" [info] Request took 0.164113s (6.093/s) .------------------------------------------+-----------. | Action | Time | +------------------------------------------+-----------+ | /greeting/hello | 0.000029s | | /greeting/world | 0.000024s | '------------------------------------------+-----------' ...
What would be common uses of this dispatch technique? It gives the possibility to split up logic that contains steps that each depend on each other. An example would be, for example, a wiki path like
/wiki/FooBarPage/rev/23/view. This chain can be easily built with these actions:
sub wiki : PathPart('wiki') Chained('/') CaptureArgs(1) { my ( $self, $c, $page_name ) = @_; # load the page named $page_name and put the object # into the stash } sub rev : PathPart('rev') Chained('wiki') CaptureArgs(1) { my ( $self, $c, $revision_id ) = @_; # use the page object in the stash to get at its # revision with number $revision_id } sub view : PathPart Chained('rev') Args(0) { my ( $self, $c ) = @_; # display the revision in our stash. Another option # would be to forward a compatible object to the action # that displays the default wiki pages, unless we want # a different interface here, for example restore # functionality. }
It would now be possible to add other endpoints, for example
restore to restore this specific revision as the current state.
You don't have to put all the chained actions in one controller. The specification of the parent through
:Chained also takes an absolute action path as its argument. Just specify it with a leading
/.
If you want, for example, to have actions for the public paths
/foo/12/edit and
/foo/12, just specify two actions with
:PathPart('foo') and
:Chained('/'). The handler for the former path needs a
:CaptureArgs(1) attribute and a endpoint with
:PathPart('edit') and
:Chained('foo'). For the latter path give the action just a
:Args(1) to mark it as endpoint. This sums up to this debugging output:
... [debug] Loaded Path Part actions: .-----------------------+------------------------------. | Path Spec | Private | +-----------------------+------------------------------+ | /foo/* | /controller/foo_view | | /foo/*/edit | /controller/foo_load (1) | | | => /controller/edit | '-----------------------+------------------------------' ...
Here's a more detailed specification of the attributes belonging to
:Chained:
Attributes
- PathPart
Sets the name of this part of the chain. If it is specified without arguments, it takes the name of the action as default. So basically
sub foo :PathPartand
sub foo :PathPart('foo')are identical. This can also contain slashes to bind to a deeper level. An action with
sub bar :PathPart('foo/bar') :Chained('/')would bind to
/foo/bar/.... If you don't specify
:PathPartit has the same effect as using
:PathPart, it would default to the action name.
- Chained
Has to be specified for every child in the chain. Possible values are absolute and relative private action paths, with the relatives pointing to the current controller, or a single slash
/to tell Catalyst that this is the root of a chain. The attribute
:Chainedwithout arguments also defaults to the
/behavior.
Because you can specify an absolute path to the parent action, it doesn't matter to Catalyst where that parent is located. So, if your design requests it, you can redispatch a chain through any controller or namespace you want.
Another interesting possibility gives
:Chained('.'), which chains itself to an action with the path of the current controller's namespace. For example:
# in MyApp::Controller::Foo sub bar : Chained CaptureArgs(1) { ... } # in MyApp::Controller::Foo::Bar sub baz : Chained('.') Args(1) { ... }
This builds up a chain like
/bar/*/baz/*. The specification of
.as the argument to Chained here chains the
bazaction to an action with the path of the current controller namespace, namely
/foo/bar. That action chains directly to
/, so the
/bar/*/baz/*chain comes out as the end product.
- CaptureArgs
Must be specified for every part of the chain that is not an endpoint. With this attribute Catalyst knows how many of the following parts of the path (separated by
/) this action wants to capture as its arguments. If it doesn't expect any, just specify
:CaptureArgs(0). The captures get passed to the action's
@_right after the context, but you can also find them as array references in
$c->request->captures->[$level]. The
$levelis the level of the action in the chain that captured the parts of the path.
An action that is part of a chain (that is, one that has a
:Chainedattribute) but has no
:CaptureArgsattribute is treated by Catalyst as a chain end.
- Args
By default, endpoints receive the rest of the arguments in the path. You can tell Catalyst through
:Argsexplicitly how many arguments your endpoint expects, just like you can with
:CaptureArgs. Note that this also affects whether this chain is invoked on a request. A chain with an endpoint specifying one argument will only match if exactly one argument exists in the path.
You can specify an exact number of arguments like
:Args(3), including
0. If you just say
:Argswithout any arguments, it is the same as leaving it out altogether: The chain is matched regardless of the number of path parts after the endpoint.
Just as with
:CaptureArgs, the arguments get passed to the action in
@_after the context object. They can also be reached through
$c->request->arguments.
Auto actions, dispatching and forwarding
Note that the list of
auto actions called depends on the private path of the endpoint of the chain, not on the chained actions way. The
auto actions will be run before the chain dispatching begins. In every other aspect,
auto actions behave as documented.
The
forwarding to other actions does just what you would expect. But if you
detach out of a chain, the rest of the chain will not get called after the
detach.
AUTHOR
Matt S Trout <mst@shadowcatsystems.co.uk>
This program is free software, you can redistribute it and/or modify it under the same terms as Perl itself.