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

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

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.

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.

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.

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:

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.

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.