Haciendo limpia en el disco duro encontré este documento escrito hace cinco años para explicar la base de la librería que se creó para una aplicación de gestión de proyectos altamente configurable. El backend era PHP orientado a objetos y en el frontend se usó Prototype.
Lo recupero aquí porque me sorprendió lo poco que he evolucionado en estos cinco años. La falta de necesidad, realmente; de aquella intentaba explicar a maquetadores web con algo de experiencia en Javascript como organizar un proyecto. Todo un cambio de mentalidad para ellos. Y dice así:
Una webapp puede tener de uno a N módulos. Cada módulo tiene su propio directorio. Los sistemas de permisos y acciones utilizarán el nombre de los directorios y de las vistas contenidas en los mismos para gestionar el acceso de los usuarios al contenido y acciones.
Usamos sformi [un pequeño proyecto privado hecho en PHP] para crear el código de los elementos principales de un Módulo: las clases y vistas, tanto principales como para cada objeto del módulo; y, por supuesto el dispatcher del módulo.
A continuación se describen los elementos del Módulo. Cada uno se corresponde con un archivo “.php”.
Vista Principal
Típicamente una lista de los objetos/entidades gestionados en el módulo. Un módulo puede tener más de una vista principal, por ejemplo “presupuestos.php” y “facturas.php”. El “index.php” de cada directorio sería siempre la vista principal por defecto.
Vista de Objeto/entidad
Una pantalla para editar los detalles de un tipo concreto de objeto/entidad. La vista contiene, típicamente, un formulario y las acciones necesarias para gestionar la vida del objeto. El generador permite crear el código para manejar Tabs dentro de la pantalla. Ejemplo “factura.php”.
Clase Principal
La clase que gestiona un módulo (ej: facturasClass). Desciende siempre de datosClass [una clase que encapsula el acceso a MySQL]. En su versión más simple tiene un método get[OBJETOS] utilizado desde la Vista Principal. En esta clase se incluyen también otros métodos comunes a todos los objetos del módulo, utilidades, etc.
Clase de Objeto
La clase para gestionar un objeto del sistema (ej: facturaClass). Desciende de la Clase Principal del Módulo al que pertenece. En su versión más simple tiene los cuatro métodos básicos de gestión de datos (get, insert, update, delete). Como regla obligatoria cada clase se corresponde con un archivo. No se define más de una clase por archivo, excepto en casos muy excepcionales.
Dispatcher
Este es el mecanismo preferido de comunicación via AJAX. Recibe, como mínimo, tres parámetros:
objeto: El ID de una clase del sistema. Este ID lo definimos en _config.php y en config.js
accion: El ID de la acción a ejecutar. Las cuatro básicas están definidas en _config.php y en config.js
id: El ID del objeto sobre el que aplicar la acción. Por ejemplo, el id de una factura o de un proyecto.
Algunas de las acciones requiere un cuarto parámetro, el payload, un objeto serializado con los datos a grabar.
Al llamar al dispatcher se instancia un objeto de la clase indicada en objeto, pasando el valor id como parámetro del constructor. A continuación ejecuta el método especificado por el la acción. Las cuatro básicas están creadas por defecto en el Dispatcher del Módulo.
Es “legal” utilizar otro mecanismo para comunicarse con el servidor, por ejemplo un “saveTask.php”, pero como norma general se utilizará el “dispatcher.php”.