Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Catalyst::DispatchTypeUseraContributed Perl Catalyst::DispatchType::Chained(3)

       Catalyst::DispatchType::Chained - Path Part DispatchType

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

	 #   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:

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

       o   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

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

       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

	 [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

	       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

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

	       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

       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.

perl v5.32.1			  2020-07-26Catalyst::DispatchType::Chained(3)


Want to link to this manual page? Use this URL:

home | help