Provided by: libcatalyst-perl_5.90124-1_all bug


       Catalyst::DispatchType::Chained - Path Part DispatchType


       Path part matching, allowing several actions to sequentially take care of processing a

         #   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 ) = @_;


       Dispatch type managing default behaviour.  For more information on dispatch types, see:

       ·   Catalyst::Manual::Intro for how they affect application authors

       ·   Catalyst::DispatchType for implementation information.


       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.

       Return a list of actions that represents a chained action. See Catalyst::Dispatcher for
       more info. You probably want to use the expand_action it provides rather than this


       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!

       And our test server would have given us this debugging output for the request:

         [debug] "GET" request for "hello/23/world/12" from ""
         [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":

               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 :PathPart" and "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 ":PathPart" it has the same effect as
               using ":PathPart", it would default to the action name.

               Sets PathPart to the path_prefix of the current controller.

       Chained Has to be specified for every child in the chain. Possible values are absolute and
               relative private action paths or a single slash "/" to tell Catalyst that this is
               the root of a chain. The attribute ":Chained" without arguments also defaults to
               the "/" behavior.  Relative action paths may use "../" to refer to actions in
               parent controllers.

               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 "baz" action 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.

               Chains an action to another action with the same name in the parent controller.
               For Example:

                 # in MyApp::Controller::Foo
                 sub bar : Chained CaptureArgs(1) { ... }

                 # in MyApp::Controller::Foo::Bar
                 sub bar : ChainedParent Args(1) { ... }

               This builds a chain like "/bar/*/bar/*".

               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 $level is 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 ":Chained" attribute)
               but has no ":CaptureArgs" attribute is treated by Catalyst as a chain end.

               Allowed values for CaptureArgs is a single integer (CaptureArgs(2), meaning two
               allowed) or you can declare a Moose, MooseX::Types or Type::Tiny named constraint
               such as CaptureArgs(Int,Str) would require two args with the first being a Integer
               and the second a string.  You may declare your own custom type constraints and
               import them into the controller namespace:

                   package MyApp::Controller::Root;

                   use Moose;
                   use MooseX::MethodAttributes;
                   use MyApp::Types qw/Int/;

                   extends 'Catalyst::Controller';

                   sub chain_base :Chained(/) CaptureArgs(1) { }

                     sub any_priority_chain :Chained(chain_base) PathPart('') Args(1) { }

                     sub int_priority_chain :Chained(chain_base) PathPart('') Args(Int) { }

               If you use a reference type constraint in CaptureArgs, it must be a type like
               Tuple in Types::Standard that allows us to determine the number of args to match.
               Otherwise this will raise an error during startup.

               See Catalyst::RouteMatching for more.

       Args    By default, endpoints receive the rest of the arguments in the path. You can tell
               Catalyst through ":Args" explicitly 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 ":Args" without any arguments, it is the same as leaving it out
               altogether: The chain is matched regardless of the number of path parts after the

               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".

               You should see 'Args' in Catalyst::Controller for more details on using type
               constraints in your Args declarations.

   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 "forward"ing to other actions does just what you would expect. i.e.  only the target
       action is run. The actions that that action is chained to are not run.  If you "detach"
       out of a chain, the rest of the chain will not get called after the "detach".

       A method which can optionally be implemented by actions to stop chain matching.

       See Catalyst::Action for further details.


       Catalyst Contributors, see


       This library is free software. You can redistribute it and/or modify it under the same
       terms as Perl itself.