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:

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

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

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

               /*bar
               /foo*bar
               *

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

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

       •   Consecutive "?" marks are captured together:

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

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

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

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