Diferencia entre revisiones de «Usuario:Lmorillas/desarrollo web servidor/web2py/flujo»

Revisión de 18:19 2 oct 2012

• LLega una petición HTTP al servidor web. El servidor procesa cada servidor en su propio hilo en paralelo
• Se procesa la cabecera HTTP y se pasa al "dispatcher"
• El "dispatcher" decide qué aplicación tiene que manejar la petición y analiza el PATH_INFO de la URL en la llamada a una función. Cada URL corresponde a una llamada a una función.
• Las peticiones de fichero de la carpeta static se maenjan directamente. Los ficheros grandes se envía directamente por streaming al cliente.

   Requests for anything but a static file are mapped into an action (i.e. a function in a controller file, in the requested application).
   Before calling the action, a few things happen: if the request header contains a session cookie for the app, the session object is retrieved; if not, a session id is created (but the session file is not saved until later); an execution environment for the request is created; models are executed in this environment.
   Finally the controller action is executed in the pre-built environment.
   If the action returns a string, this is returned to the client (or if the action returns a web2py HTML helper object, it is serialized and returned to the client).
   If the action returns an iterable, this is used to loop and stream the data to the client.
   If the action returns a dictionary, web2py tries to locate a view to render the dictionary. The view must have the same name as the action (unless specified otherwise) and the same extension as the requested page (defaults to .html); on failure, web2py may pick up a generic view (if available and if enabled). The view sees every variable defined in the models as well as those in the dictionary returned by the action, but does not see global variables defined in the controller.
   The entire user code is executed in a single transaction unless specified otherwise.
   If the user code succeeds, the transaction is committed.
   If the user code fails, the traceback is stored in a ticket, and a ticket ID is issued to the client. Only the system administrator can search and read the tracebacks in tickets.

There are some caveats to keep in mind:

   Models in the same folder/subfolder are executed in alphabetical order.
   Any variable defined in a model will be visible to other models following alphabetically, to the controllers, and to the views.
   Models in subfolders are executed conditionally. For example, if the user has requested "/a/c/f" where "a" is the application, "c" is the controller, and "f" is the function (action), then the following models are executed:

applications/a/models/*.py applications/a/models/c/*.py applications/a/models/c/f/*.py

   The requested controller is executed and the requested function is called. This means all top-level code in the controller is also executed at every request for that controller.
   The view is only called if the action returns a dictionary.
   If a view is not found, web2py tries to use a generic view. By default, generic views are disabled, although the 'welcome' app includes a line in /models/db.py to enable them on localhost only. They can be enabled per extension type and per action (using response.generic_patterns). In general, generic views are a development tool and typically should not be used in production. If you want some actions to use a generic view, list those actions in response.generic_patterns (discussed in more detail in the chapter on Services).