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.