Ver documentación general en miLibreria/doc Indice Introducción Seguridad Ante cambios profundos Ruteo a los requerimientos desde Zend hacia Laravel CSS y JS Zend: Sesión --- Introducción El proyecto original fue construído bajo Zend 1. La intención es que ese proyecto se mantenga en el tiempo con los mínimos agregados posibles y que todo lo nuevo sea desarrollado bajo Laravel. Ambos proyectos convivirán simultáneamente. --- Seguridad La parte desarrollada en Laravel, aun no válida si el usuario está logueado. Resta implementar un sistema de verificación vía cookies u otro metódo. --- Ante cambios profundos Pasos para realizar cambios importantes en "laravel_academico": Actualizar la carpeta "miLibreria" Actualizar las últimas sentencias aplicadas a la base de datos detalladas en "sentencias_evolutivas.sql". Actualizar las views desde "gestion_estudiantes" en "views.sql". --- Ruteo a los requerimientos desde Zend hacia Laravel: El contenido de las pantallas bajo Zend se administra desde el modelo Datagrid.php . En Zend no hay una indicación expresa de la url necesaria para cada planilla. Datagrid.php se desentiende de esa tarea. En gestion_estudiantes/application/modules/admin/views/scripts/administrador existe la view principal que presenta los filtros y menús principales: datagrid.phtml El ruteo exacto para cada requerimiento es resuelto por admin/AdministadorController.php La url llega indicando que planilla trabaja y otros datos GET o POST. Y AdministradorController evalua que planilla debe ser atendida. Y la vista principal, datagrid.phtml, carga todas las rutas que maneja Laravel, declaradas en RutasLaravelAcademico. Así si es una de esas, ejecuta la nomenclatura que será atajada por el htaccess y derivado así a la carpeta de laravel. En Laravel, las rutas se construyen en web.php . Es importante recordar que el menú principal, toma los filtros seleccionados, la sede, y envía todo eso con una solicitud post. Dado que la solicitud no es a partir de rellenar un formulario, la url debe declarar que no usará csrf, en web.php . --- CSS y JS MUY IMPORTANTE !!!! La forma en que todo fue construído plantea ciertas particularidades que es necesario comprender para evitar perder tiempo buscando porque algo no responde como se supone que debería. La salida a pantalla de Zend, corresponde a un iframe puesto por Practicantes, y podría ser incluso un div general por lo que en sí, no se debe generar un layout completo que contenga el tag html ni el body. Pero, para trabajar en mi pc, en modo local, hay un pequeño layout que coloca estos tags junto con una cabecera y un menú con la misma funcionalidad que lo hace Practicantes, en test y prod. En cuanto a la carga de JS y CSS En su momento, para mejorar la performance, elabore un compilador de js y css que corre 1 vez para generar un CSS.txt y un JS.txt. Cuando estos archivos existen, el compilador ya no vuelve a crearlos. Es decir, que si hay cambios de js o css, habrá que eliminar esos .txt, para que el proceso vuelva a crearlos. El proceso en si, al recibir un requerimiento, va arrastrando a una cola, una lista de nombres de css y js que requiere para finalmente renderear la view. Y si los archivos .txt mencionados antes no existen, los genera, haciendo un compendio de todos los css y js involucrados. ¿dónde?¿quién?¿cómo? Para este proyecto de la Escuela de natha yoga, hay una view que hace de embudo de cualquier solicitud: datagrid.phtml. Esta view, coloca los menús generales, y define el espacio donde se volcará el datagrid correspondiente. En sí, hace como de sub layout. Este sublayout, es quién genera, si corresponde, CSS.txt y JS.txt Estos archivos puede que varíen según el ambiente donde se este trabajando, es decir, que no puede simplemente copiarse y pegarse en distintos ambientes, sino que deben ser borrados, para que automáticamente se generen al realizar cualquier solicitud. La mayoría de estos archivos estaran en MiLibrary/modulos/default/views/scripts/. Laravel Las pantallas de Laravel renderean sus pantallas con una particularidad, y es que los css y js, ya se encuentran levantados por Zend, con lo que salvo particularidades propias a sus propios render, no deben volver a cargar los css y js generales. Aunque mucha funcionalidad existe duplicada en mi libreria/miLaravel, ya que ciertas cosas se programan distinto entre Laravel y Zend. Esto me ha planteado cierta suciedad de código al tener que repetir cosas casi iguales. En general, todo funcionará de acuerdo a lo cargado por Zend. Cuando una view blade requiera cargar css o js particular lo hará escribiendo el estilo o js necesario en la propia view o tal como se hace siempre en Laravel, usando la directiva @include. Laravel, crea archivos temporales en cache con código css y js. Laravel 8 (y creo que también el resto de las versiones), sin utilizar npm, compila los css y js en archivos propios temporales. (en storage/frameworks/views/) --- Zend: Sesión Como he trabajado la data en Sesión, tiene mucho por refactorizar. En su momento para lograr mayor eficiencia y menos tareas repetidas, mucha funcionalidad la lleve a sesión, con lo que se recarga de mucha data. En un futuro refactoring, buscaria minimizar la sesión para limpiarla, sin importar la repetición de tareas en cada requerimiento. Porque en sí, la performance que se degrada es muy sútil.