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

FreeBSD Manual Pages

  
 
  

home | help
Jifty::Dispatcher(3)  User Contributed Perl Documentation Jifty::Dispatcher(3)

NAME
       Jifty::Dispatcher - The Jifty Dispatcher

SYNOPSIS
       In MyApp::Dispatcher:

	   package MyApp::Dispatcher;
	   use Jifty::Dispatcher -base;

	   under ['blog', 'wiki'] => [
	       run {
		   default model => "MyApp::Model::\u$1"
	       },
	       on PUT 'entries/*' => run {
		   set entry_id	=> $1;
		   show	'/display/entry';
	       },
	       on '*/*'	=> run {
		   my ($page, $op) = ($1, $2);
		   my $item = get('model')->load($page)	or next_rule;

		   set item => $item;
		   set page => $page;
		   set op   => $op;

		   show	"/display/$op";
	       },
	       on '*' => run { dispatch	"$1/view" },
	       on ''  => show '/display/list',
	   ];
	   under qr{logs/(\d+)}	=> [
	       when { $1 > 100 } => show '/error',
	       set model => 'MyApp::Model::Log',
	       run { dispatch "/wiki/LogPage-$1" },
	   ];
	   # ... more rules ...

DESCRIPTION
       "Jifty::Dispatcher" takes requests for pages, walks through a dispatch
       table, possibly running code or transforming the	request	before finally
       handing off control to the templating system to display the page	the
       user requested or whatever else the system has decided to display
       instead.

       Generally, this is not the place	to be performing model and user
       specific	access control checks or updating your database	based on what
       the user	has sent in. You want to do that in your model classes.	(Well,
       we want you to do that, but you're free to ignore our advice).

       The Dispatcher runs rules in several stages:

       before
	   before rules	are run	before Jifty evaluates actions.	They're	the
	   perfect place to enable or disable Jifty::Actions using "allow" in
	   Jifty::API and "deny" in Jifty::API or to completely	disallow user
	   access to private component templates such as the _elements
	   directory in	a default Jifty	application.  They're also the right
	   way to enable Jifty::LetMe actions.

	   You can entirely stop processing with the "redirect", "tangent" and
	   "abort" directives, though "after" rules will still run.

       on  on rules are	run after Jifty	evaluates actions, so they have	full
	   access to the results actions users have performed. They're the
	   right place to set up view-specific objects or load up values for
	   your	templates.

	   Dispatcher directives are evaluated in order	until we get to	either
	   a "show", "redirect", "tangent" or "abort".

       after
	   after rules let you clean up	after rendering	your page. Delete your
	   cache files,	write your transaction logs, whatever.

	   At this point, it's too late	to "show", "redirect", "tangent" or
	   "abort" page	display.

       "Jifty::Dispatcher" is intended to replace all the autohandler,
       dhandler	and "index.html" boilerplate code commonly found in Mason
       applications, but there's nothing stopping you from using those
       features	in your	application when they're more convenient.

       Each directive's	code block runs	in its own scope, but all share	a
       common $Dispatcher object.

Plugins	and rule ordering
       By default, Jifty::Plugin dispatcher rules are added in the order they
       are specified in	the application's configuration	file; that is, after
       all the plugin dispatchers have run in order, then the application's
       dispatcher runs.	 It is possible	to specify rules which should be
       reordered with respect to this rule, however.  This is done by using a
       variant on the "before" and "after" syntax:

	   before plugin NAME =>
	       RULE(S);

	   after plugin	NAME =>
	       RULE(S);

	   after app,
	       RULE(S)

       "NAME" may either be a string, which must match the plugin name
       exactly,	or a regular expression, which is matched against the plugin
       name.  The rule will be placed at the first boundary that it matches --
       that is,	given a	"before	plugin qr/^Jifty::Plugin::Auth::/" and both a
       "Jifty::Plugin::Auth::Basic" and	a "Jifty::Plugin::Auth::Complex", the
       rules will be placed before the first.

       "after app" inserts the following "RULES" after the application's
       dispatcher rules, and is	identical to, but hopefully clearer than,
       "after plugin Jifty => RULES".

       "RULES" may either be a single "before",	"on", "under", or "after" rule
       to change the ordering of, or an	array reference	of rules to reorder.

Data your dispatch routines has	access to
   request
       The current Jifty::Request object.

   $Dispatcher
       The current dispatcher object.

   get $arg
       Return the argument value.

Things your dispatch routine might do
   under $match	=> $rule
       Match against the current requested path.  If matched, set the current
       context to the directory	and process the	rule.

       The $rule may be	an array reference of more rules, a code reference, a
       method name of your dispatcher class, or	a fully	qualified subroutine
       name.

       All wildcards in	the $match string becomes capturing regex patterns.
       You can also pass in an array reference of matches, or a	regex pattern.

       The $match string may be	qualified with a HTTP method name or protocol,
       such as

       GET
       POST
       PUT
       OPTIONS
       DELETE
       HEAD
       HTTPS
       HTTP

   on $match =>	$rule
       Like "under", except it has to match the	whole path instead of just the
       prefix.	Does not set current directory context for its rules.

   before $match => $rule
       Just like "on", except it runs before actions are evaluated.

   after $match	=> $rule
       Just like "on", except it runs after the	page is	rendered.

   when	{...} => $rule
       Like "under", except using an user-supplied test	condition.  You	can
       stick any Perl you want inside the {...}; it's just an anonymous
       subroutine.

   run {...}
       Run a block of code unconditionally; all	rules are allowed inside a
       "run" block, as well as user code.  You can think of the	{...} as an
       anonymous subroutine.

   stream {...}
       Run a block of code unconditionally, which should return	a coderef that
       is a PSGI streamy response.

   set $arg => $val
       Adds an argument	to what	we're passing to our template, overriding any
       value the user sent or we've already set.

   default $arg	=> $val
       Adds an argument	to what	we're passing to our template, but only	if it
       is not defined currently.

   del $arg
       Deletes an argument we were passing to our template.

   show	$component
       Display the presentation	component.  If not specified, use the request
       path as the default page.

   dispatch $path
       Dispatch	again using $path as the request path, preserving args.

   next_rule
       Break out from the current "run"	block and go on	the next rule.

   last_rule
       Break out from the current "run"	block and stop running rules in	this
       stage.

   abort $code
       Abort the request; this skips straight to the cleanup stage.

       If $code	is specified, it's used	as the HTTP status code.

   redirect $uri
       Redirect	to another URI.

   tangent $uri
       Take a continuation here, and tangent to	another	URI.

   plugin
   app
       See "Plugins and	rule ordering",	above.

   import
       Jifty::Dispatcher is an Exporter, that is, part of its role is to blast
       a bunch of symbols into another package.	In this	case, that other
       package is the dispatcher for your application.

       You never call import directly. Just:

	   use Jifty::Dispatcher -base;

       in "MyApp::Dispatcher"

   rules STAGE
       Returns an array	of all the rules for the stage STAGE.

       Valid values for	STAGE are

       SETUP
       RUN
       CLEANUP

   new
       Creates a new Jifty::Dispatcher object. You probably don't ever want to
       do this.	(Jifty.pm does it for you)

   handle_request
       Actually	do what	your dispatcher	does. For now, the right thing to do
       is to put the following two lines first:

	   require MyApp::Dispatcher;
	   MyApp::Dispatcher->handle_request;

   _handle_stage NAME, EXTRA_RULES
       Handles the all rules in	the stage named	"NAME".	 Additionally, any
       other arguments passed after the	stage "NAME" are added to the end of
       the rules for that stage.

       This is the unit	which calling "last_rule" skips	to the end of.

   _handle_rules RULESET
       When handed an arrayref or array	of rules (RULESET), walks through the
       rules in	order, executing as it goes.

   _handle_rule	RULE
       When handed a single rule in the	form of	a coderef, "_handle_rule",
       calls "_do_run" on that rule and	returns	the result. When handed	a rule
       that turns out to be an array of	subrules, recursively calls itself and
       evaluates the subrules in order.

   _do_under
       This method is called by	the dispatcher internally. You shouldn't need
       to.

   _do_when
       This method is called by	the dispatcher internally. You shouldn't need
       to.

   _do_before
       This method is called by	the dispatcher internally. You shouldn't need
       to.

   _do_on
       This method is called by	the dispatcher internally. You shouldn't need
       to.

   _do_after
       This method is called by	the dispatcher internally. You shouldn't need
       to.

   already_run
       Returns true if the code	block has run once already in this request.
       This can	be useful for 'after' rules to ensure that they	only run once,
       even if there is	a sub-dispatch which would cause it to run more	than
       once.  The idiom	is:

	   after '/some/path/*'	=> run {
	       return if already_run;
	       # ...
	   };

   _do_redirect	PATH
       This method is called by	the dispatcher internally. You shouldn't need
       to.

       Redirect	the user to the	URL provided in	the mandatory PATH argument.

   _do_tangent PATH
       This method is called by	the dispatcher internally. You shouldn't need
       to.

       Take a tangent to the URL provided in the mandatory PATH	argument.
       (See Jifty::Manual::Continuation	for more about tangents.)

   _do_stream CODE
       The method is called by the dispatcher internally. You shouldn't	need
       to.

       Take a coderef that returns a PSGI streamy response code.

   _do_abort
       This method is called by	the dispatcher internally. You shouldn't need
       to.

       Don't display any page. just stop.

   _do_show [PATH]
       This method is called by	the dispatcher internally. You shouldn't need
       to.

       Render a	template. If the scalar	argument "PATH"	is given, render that
       component.  Otherwise, just render whatever we were going to anyway.

   _do_dispatch	[PATH]
       First, this routine runs	all the	"before" dispatcher rules, then	it
       runs Jifty->web->handle_request(), then it runs all the main "on"
       rules, evaluating each one in turn.  If it gets through all the rules
       without running an "abort", "redirect" or "show"	directive, it "shows"
       the template originally requested.

       Once it's done with that, it runs all the cleanup rules defined with
       "after".

   _match CONDITION
       Returns the regular expression matched if the current request fits the
       condition defined by CONDITION.

       "CONDITION" can be a regular expression,	a "simple string" with shell
       wildcard	characters ("*", "?", "#", "[]", "{}") to match	against, or an
       arrayref	or hashref of those. It	should even be nestable.

       Arrayref	conditions represents alternatives: the	match succeeds as soon
       as the first match is found.

       Hashref conditions are conjunctions: each non-empty hash	key triggers a
       separate	"_match_$keyname" call on the dispatcher object. For example,
       a "method" key would call "_match_method" with its value	to be matched
       against.	 After each subcondition is tried (in lexicographical order)
       and succeeded, the value	associated with	the '' key is matched again as
       the condition.

   _match_method METHOD
       Takes an	HTTP method. Returns true if the current request came in with
       that method.

   _match_https
       Returns true if the current request is under SSL.

   _match_http
       Returns true if the current request is not under	SSL.

   _compile_condition CONDITION
       Takes a condition defined as a simple string and	return it as a regex
       condition.

   _compile_glob METAEXPRESSION
       Private function.

       Turns a metaexpression containing "*", "?" and "#" into a capturing
       regex pattern.

       Also supports the non-capturing "[]" and	"{}" notations.

       The rules are:

       o   A "*" between two "/" characters, or	between	a "/" and end of
	   string, should match	one or more non-slash characters:

	       /foo/*/bar
	       /foo/*/
	       /foo/*
	       /*

       o   All other "*" can match zero	or more	non-slash characters:

	       /*bar
	       /foo*bar
	       *

       o   Two stars ("**") can	match zero or more characters, including
	   slash:

	       /**/bar
	       /foo/**
	       **

       o   Consecutive "?" marks are captured together:

	       /foo???bar      # One capture for ???
	       /foo??*	       # Two captures, one for ?? and one for *

       o   The "#" character captures one or more digit	characters.

       o   Brackets such as "[a-z]" denote character classes; they are not
	   captured.

       o   Braces such as "{xxx,yyy}]" denote alternations; they are not
	   captured.

   import_plugins
       Imports rules from "plugins" in Jifty into the main dispatcher's	space.

perl v5.32.1			  2014-12-09		  Jifty::Dispatcher(3)

NAME | SYNOPSIS | DESCRIPTION | Plugins and rule ordering | Data your dispatch routines has access to | Things your dispatch routine might do

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=Jifty::Dispatcher&sektion=3&manpath=FreeBSD+13.1-RELEASE+and+Ports>

home | help