Provided by: libjifty-perl_1.10518+dfsg-3ubuntu1_all bug


       Jifty::Manual::RequestHandling - Jifty's request handling process


       This document outlines some of Jifty's inside in order to help you to understand what
       happens during the request processing phase.


       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:

               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.

               This final stage of the dispatcher will run all rules marked with the word

       cleanup several things
           Finally, the eventually modified session-record is flushed and some internally
           allocated structures get deallocated.


       Jifty::Handler, Jifty::Dispatcher, Jifty::Request, Jifty::Response