3.4.0

Seguimiento de la ejecución

Para desarrolladores nuevos a las aplicaciones Web surge un nuevo concepto llamado request o pedido que marca la comunicación entre el lado cliente y servidor.

Al no permanecer en memoria entre pedidos, PHP almacena un entorno mínimo de datos en las llamadas variables de sesión, por ejemplo mantienen el usuario logueado y toda aquella información persistente durante la sesión del usuario. Esta información de la sesión es almacenada por PHP en archivos físicos en forma predeterminada, con lo cual prácticamente no hay memoria compartida entre distintos pedidos de página. Toda otra información es descartada cuando la página termina de servirse.

Ingreso

Las sesiones de trabajo en los proyectos creados con Toba siempre pasan a través de un único [referencia/PuntosDeAcceso punto de acceso], esto se conoce como FrontController dejando de lado el PageController clásico en aplicaciones PHP. En un PageController existen un gran número de páginas web publicadas, cada una atendiendo distintas operaciones y casos dentro de las operaciones. En cambio en un controlador frontal la URL inicial es siempre la misma, existe una sola página publicada. En el caso de Toba esa página por defecto es aplicacion.php. La URL que ingresa el usuario direcciona a este punto de acceso, por ejemplo:

    http://localhost/mi_proyecto/aplicacion.php

Es por este archivo (aplicacion.php) por donde pasarán los siguientes pedidos, recibiendo como parámetros la operación y atributos propios de esa operación, entre otras cosas. Entre la configuración estática del proyecto, el alias donde se publica y el punto de acceso se reparten todas las configuraciones:

  • Qúe instalación se utiliza (Constante Apache TOBA_DIR)
  • Qué instancia posee los metadatos a utilizar. (Constante Apache TOBA_INSTANCIA)
  • Qué proyecto se va a ejecutar (Constante Apache TOBA_PROYECTO)
  • En donde se encuentra ubicado el contenido estático de toba: css, js e imagenes (Constante Apache TOBA_ALIAS)
  • En dónde se encuentra ubicado el contenido estático del proyecto (Constante Apache TOBA_PROYECTO_ALIAS)
  • Ver más configuraciones disponibles en el punto de acceso.

Acceso al núcleo

El fin del punto de acceso se incluye al núcleo de toba, El núcleo de Toba es la espina dorsal de la ejecución y posee distintas entradas:

  • Acceso via Web: el clásico que se utiliza generalmente en la aplicación

  • Acceso via Consola: utilizado para procesos batch o administrativos que no requieren interacción con un usuario final.

El acceso web es el más rico y es el que seguiremos en esta traza.

El núcleo determina la [referencia/Instancia instancia] y el [referencia/Proyecto proyecto] en el cual se debe iniciar o refrescar la sesión. El inicio de sesión se da cuando el usuario brinda su contraseña allí se produce la autentificación del mismo y se dice que la sesión está iniciada. A partir de allí los sucesivos pedidos de página por parte del usuario utilizan esta sesión refrescándola. Se incluye la carpeta mi_proyecto/php dentro del include_path de PHP y se ejecutan las ventanas de la sesión. Ver más detalles del [referencia/Login proceso de login].

Luego de esto, en cada pedido de página se ejecuta una ventana del proyecto llamada contexto de ejecución. Esta clase contexto_ejecucion tiene un método conf__inicial que se ejecuta siempre al ingresar el proyecto a la ejecución del request (pedido de página). Por este motivo es util para agregar configuraciones globales al proyecto.

Ejecución de la Solicitud

Luego se busca que operación fue solicitada via la URL, esto lo hace una clase llamada toba_memoria que enmascara al GET/POST/SESSION de PHP. Para saber cómo ejecutar la operación se busca en sus metadatos, utilizando el Constructor encargado de buscar en la base de datos de la instancia o en su versión pre-compilada la información asociada a la operación.

Una vez conocidos los metadatos de la operación toma el controlador de la ejecución su [referencia/Solicitud Solicitud] asociada. El caso general es utilizar la llamada solicitud_web que introduce las etapas de:

  • Creación de la Zona asociada a la operación, si posee

  • Crear los Componentes asociados directamente a la operación. Antes se les busca su definición en los metadatos utilizando el Constructor de componentes.

  • Disparar en estos componentes la atención de Eventos producidos en la etapa anterior (Antender el $\_POST)

  • Generación del Servicio solicitado, generalmente generar_html:

    • Utilizar el tipo de página para incluir el encabezado y pie de página e incluir recursos estáticos.

    • Disparar en los componentes la generación de la interface

    • Incluir los consumos javascript de estos componentes.

Generalmente el componente cabecera asociado a la operación es el llamado Controlador de interface

Componentes

La solicitud_web delega la ejecución a los componentes, y en particular al Controlador de interface asociado directamente a la operación. Este ci es la raíz de un árbol de componentes donde se van a producir las etapas principales de ejecución en el pedido de página, las cuales siguen un orden de ejecución especifico:

Construcción

Una vez que el constructor consigue la definición del componente, este se crea como objeto php y se inicializa. Algunas veces en el código se referencia a esto como carga del componente, pero no tiene nada que ver con la carga de datos que sufren en la configuración los componentes.

Atención de eventos

El CI busca aquellas dependencias que participaron en la construcción de la pantalla anterior y las crea. La creación de componentes es siempre recursiva (un ci puede tener otros cis y así sucesivamente). A estos componentes se les pide que disparen sus eventos, es decir que lean del $_POST para ver que pasó en el browser. Se buscan los listeners definidos en el ci contenedor y se les pasa la info del evento.

    function evt__listado__seleccion($id);
    function evt__formulario__modificacion($datos);
    function evt__cancelar();

Configuración

Una vez que todo el pasado fue atendido, es necesario comenzar la construcción de una nueva página. El ci invoca a la ventana de configuración:

    function conf()

Luego se decide que pantalla mostrar, ya sea porque el usuario la pidio o porque el programador la forzo en los eventos o en la configuración general. Una vez que se sabe cual es la pantalla se invoca su configuración:

    function conf__pant_cheque()

En la configuración se pueden agregar/quitar depedencias, eventos o tabs. Una vez que esta configuración termina se determina qué dependencias se van a mostrar en la pantalla y para cada una de ellas se ejecuta su configuración

    function conf__form_cheque(toba_ei_formulario $form);
    function conf__listado(toba_ei_cuadro $cuadro);
    ...

En estas configuraciones se puede consumir el API de estos componentes para cargarle datos, ocultar algunas cosas y demás.

Generación del servicio

Una vez que todo está configurado se invoca la generación de html de todos los componentes participantes en el servicio. Generalmente en esto el proyecto no tiene ventanas de programación, exceptuando algunos componentes que permiten cambiar su layout:

    function generar_layout();

Ejecución en el cliente

Una vez que el HTML es ejecutado por el browser los componentes cuentan en javascript a representantes similares a los de PHP. Estos objetos javascript tienen una API que posibilita decidir en forma conjunta cuando y cómo viajar nuevamente al servidor.

Cuando un componente decide viajar al servidor (proceso denominado submit), se pregunta a todos los componentes participantes si pueden hacerlo (validando su estado) y en caso de hacerlo dejan en el $_POST las pistas para que posteriormente la atención de eventos de esos componentes en PHP puedan atraparlas.