This document discusses the ins and outs of getting data from the web browser (or any other source) and figuring out what it means.
Most of the time,
you won't need to worry about the details,
but they are provided below if you're curious.

This class parses the submission and makes it available as a protocol-independent Jifty::Request object.

A request may contain one or more actions; these are represented as Jifty::Request::Action objects.
Each action request has a moniker,
a set of submitted arguments,
and an implementation class.
By default,
all actions that are submitted are run; it is possible to only mark a subset of the submitted actions as "active",
and only the active actions will be run.
These will eventually become full-fledge Jifty::Action objects.

State variables are used to pass around bits of information which are needed more than once but not often enough to be stored in the session.
Additionally,
they are per-browser window,
unlike session information.

Fragments are standalone bits of reusable code.
They are most commonly used in the context of AJAX,
where fragments are the building blocks that can be updated independently.
A request is either for a full page,
or for multiple independent fragments.
See Jifty::Web::PageRegion.

Calls the Jifty::Continuation associated with this request,
if there is one.
Returns true if the continuation was called successfully -- if calling the continuation requires a redirect,
this function will throw an exception to its enclosing dispatcher.

Adds a Jifty::Request::Action with the given moniker to the request.
If the request already contains an action with that moniker,
it merges it in,
overriding the implementation class,
active state,
and individual arguments.
Returns the newly added Jifty::Request::Action.

For each action, the client sends a query argument whose name is J:A-moniker and whose value is the fully qualified class name of the action's implementation class. This is the action "registration." The registration may also take the form J:A-order-moniker, which also sets the action's run order.

The action's arguments are specified with query arguments of the form J:A:F-argumentname-moniker. To cope with checkboxes and the like (which don't submit anything when left unchecked) we provide a level of fallback, which is checked if the first doesn't exist: J:A:F:F-argumentname-moniker.

The current continuation set by passing the parameter J:C, which is set to the id of the continuation. To create a new continuation, the parameter J:CREATE is passed. Calling a continuation is a simple as passing J:CALL with the id of the continuation to call; this will redirect to the appropriate url, with J:RETURN set.

The existence of J:VALIDATE says that the request is only validating arguments. J:ACTIONS is set to a semicolon-separated list of monikers; the actions with those monikers will be marked active, while all other actions are marked inactive. In the absence of J:ACTIONS, all actions are active.