Catalyst::DispatchType::Chained man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

Catalyst::DispatchTypeUseraContributed Perl Catalyst::DispatchType::Chained(3)

NAME
       Catalyst::DispatchType::Chained - Path Part DispatchType

SYNOPSIS
       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 ) = @_;
	     ...
	 }

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

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.

   $c->expand_action($action)
       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.

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

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

       ChainedParent
	       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::Moo
		 sub bar : ChainedParent Args(1) { ... }

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

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

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

   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. But
       if you "detach" out of a chain, the rest of the chain will not get
       called after the "detach".

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

       See Catalyst::Action for further details.

AUTHORS
       Catalyst Contributors, see Catalyst.pm

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

perl v5.14.2			  2012-03-08Catalyst::DispatchType::Chained(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net