NAME¶
Jifty::Manual::RequestHandling - Jifty's request handling process
DESCRIPTION¶
This document outlines some of Jifty's inside in order to help you to understand
what happens during the request processing phase.
THE HANDLER¶
As soon as a HTTP request (whatever the method might be, like GET, POST, PUT,
...) arrives at Jifty's border, the request is forwarded to a handler. By
default, "Jifty->handler" points to a Jifty::Handler object that
is responsible for handling an incoming request. The handler receives a CGI
object on which it operates.
The major steps in the request handling process are:¶
- refresh eventually modified modules in develop mode
- This allows a perl developer to change perl modules being
used in a Jifty application without the need to restart the server which
would otherwise become necessary. This is never done on a live
environment.
- build a stash
- The stash is a storage area that can be reached by simply
accessing "Jifty->handler->stash->{some_key}". The
stash will start fresh with every request and lives for the entire
lifetime of a request. Using the stash, transporting data between
otherwise unconnected modules will become possible.
- construct a request and response object
- Using the CGI object, a Jifty::Request object is
constructed and its data is populated with the CGI object's data. The
request can be reached later using "Jifty->web->request".
The request holds information about all actions involved, all page
fragments, contains state variables and arguments (usually GET/POST
parameters).
Also, an empty Jifty::Response object is constructed that contains one or
more Jifty::Result objects, each of which holds one Jifty::Action's
result. The response object can be retrieved with the
"Jifty->web->response" method.
- setup plugins
- For every registered Jifty::Plugin, some kind of
per-request initialization is performed allowing the actions provided by
each plugin to run.
- handle static content
- If the requested URI points to some existing static content
being housed in a "static" directory, this content is
handled.
- setup the session
- Based on a cookie that is sent with every HTTP response,
the current user is assigned a unique session. The session is stored in a
Jifty::Web::Session object and can be accessed using the
"Jifty->web->session" method.
- return from a continuation if requested
- If there is an open continuation on the stack (e.g. from a
"Jifty->web->tangent" link) and the return has been
requested (e.g. by a "Jifty->web->return" link), the
return will execute at this stage.
- handle dynamic request unless already served
- First, the user is given a cookie containing the
session-id. Then, the request is forwarded to
"Jifty->handler->dispatcher", a Jifty::Dispatcher object
to handle the request. The dispatcher works through the following
steps:
- setup
- In this stage, all rules in the dispatcher that are marked
with the word "before" are run.
- run the actions involved
- Every Jifty::Action that is registered in a form or
involved in a link or button is run in this stage.
- run dispatching rules
- This stage is responsible for working through all rules
marked by words like "under", "on", "when"
and so on. This is a point where based on the URI or parameters the
template to get displayed may still be modified, data get retrieved,
additional actions run or the template's parameters get adjusted.
- show the page
- Here, the template displaying the page is run.
- cleanup
- This final stage of the dispatcher will run all rules
marked with the word "after".
- cleanup several things
- Finally, the eventually modified session-record is flushed
and some internally allocated structures get deallocated.
SEE ALSO¶
Jifty::Handler, Jifty::Dispatcher, Jifty::Request, Jifty::Response