Usuario:Lmorillas/desarrollo web servidor/web2py/flujo - Historial de revisiones

Lmorillas en 17:50 18 nov 2013

2013-11-18T17:50:13Z

Lmorillas en 06:45 2 oct 2012

2012-10-02T06:45:21Z

Lmorillas en 05:29 2 oct 2012

2012-10-02T05:29:38Z

Lmorillas: Página creada con '{{MiTitulo|Flujo de Web2py}} * 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…'

2012-10-02T05:19:14Z

Página creada con '{{MiTitulo|Flujo de Web2py}} * 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…'

Página nueva

{{MiTitulo|Flujo de Web2py}}

* 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).

← Revisión anterior		Revisión de 17:50 18 nov 2013
Línea 16:		Línea 16:
	* Si devuelve un diccionario, trata de localizar la vista que formatea el diccionario. La vista tiene que tener el mismo nombre que la acción y la misma extensión que la página solicitada (por defecto .html) Si no, web2py usa unan vista genérica.		* Si devuelve un diccionario, trata de localizar la vista que formatea el diccionario. La vista tiene que tener el mismo nombre que la acción y la misma extensión que la página solicitada (por defecto .html) Si no, web2py usa unan vista genérica.
	}}		}}
		+
		+
		+	http://www.latinuxpress.com/books/drafts/web2py/_images/diagram1.png

@@ Línea 1: / Línea 1: @@
 {{MiTitulo|Flujo de Web2py}}
 * 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"
@@ Línea 14: / Línea 15: @@
 * Si la acción devuelve un objeto iterable, se recorre y se envían los datos al cliente
 * Si devuelve un diccionario, trata de localizar la vista que formatea el diccionario. La vista tiene que tener el mismo nombre que la acción y la misma extensión que la página solicitada (por defecto .html) Si no, web2py usa unan vista genérica.

@@ Línea 5: / Línea 5: @@
 * 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.
+* El resto de peticiones se mapean a una acción (función en un fichero de controlador) en la aplicación solicitada.
-    Requests for anything but a static file are mapped into an action (i.e. a function in a controller file, in the requested application).
+* Antes de llamar a la función:
-    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.
+** Si el encabezado de la petición tiene una cookie de sesión para la app, se recupera el objeto sesión,
-    Finally the controller action is executed in the pre-built environment.
+** Si no, se crea un id de sesión.
-    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).
+** Se crea un entorno de ejecución para la petición. Los modelos se ejecutarán en este entorno.
-    If the action returns an iterable, this is used to loop and stream the data to the client.
+* Finalmente la acción del controlador se ejecuta en este entorno.
-    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.
+* Si la acción devuelve una cadena, ésta se devuelve al cliente (los HTML helpsers de web2py se serializan y devuelven al cliente también)
-    The entire user code is executed in a single transaction unless specified otherwise.
+* Si la acción devuelve un objeto iterable, se recorre y se envían los datos al cliente
-    If the user code succeeds, the transaction is committed.
+* Si devuelve un diccionario, trata de localizar la vista que formatea el diccionario. La vista tiene que tener el mismo nombre que la acción y la misma extensión que la página solicitada (por defecto .html) Si no, web2py usa unan vista genérica.
-    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).