¿Qué es una aplicación grande en el entorno de PHPrunner? Que yo conozca no existe una definición concreta. Para mí, es grande cuando genera más de 3000 ficheros o cuando tiene más de 50 tablas. Espero que este criterio os sirva.

Yo he estado trabajando con aplicaciones PHPRunner que tenían ambos criterios, e incluso, éramos varias personas desarrollando el aplicativo.

En este artículo deseo comentaros los criterios y formas de trabajar con este tipo de aplicaciones, criterios y formas, que veo razonables independientemente de la herramienta de codificación. Con ello no quiero significar que la versión 11 de PHPRunner, no sea positiva, sino que para muchos, muchos casos, no era esencial para gestionar proyectos grandes o con varios desarrolladores.

Objetivo:

Explicar criterios y soluciones, a emplear, para poder gestionar aplicaciones grandes.

1. Dividir aplicaciones en módulos e interconectarlos, para facilitar la gestión de acceso a los usuarios.
2. La librerías externas, ubicarlas fuera del proyecto de PHPRunner.
3. Trabajo de varios desarrolladores en el proyecto. División de actividades y forma de escribir el código.

DEMO de división de aplicaciones en módulos.
– https://fhumanes.com/app1/
– https://fhumanes.com/app2/

Usuarios:
– user1/user1 . Tiene perfil de grupo en las dos APP
– user2/user2. Tiene perfil de grupo en una APP

Solución Técnica:

Voy a intentar explicar uno a uno, los criterios que he utilizado al definir los objetivos.

1.- Dividir las aplicaciones muy grandes en módulos.

Es un criterio utilizado hace muchos años en el desarrollo de software la utilización de la metodología “Top-Down”, que no es otra cosa que la división del problema/aplicación en  módulos, de tal forma que la descomposición en unidades más pequeñas, hace que sean unidades más fáciles de gestionar y desarrollar. Por ello, si tenemos un aplicativo con muchas tablas, codificación, etc., seguramente podamos dividirla en unidades (Módulos) mucho más sencillos de definir y codificar.

Por ejemplo, tenemos que desarrollar la gestión de una empresa y podemos hacer un único desarrollo o la división en módulos lógicos para el usuario, por ejemplo:

• Gestión de Compras y Almacenes.
• Gestión de Clientes y Facturación.
• Contabilidad general y analítica.
• Tesorería.
• Gestión de personal.
• Nómina y Seguros Sociales.

Otra forma en la que podíamos dividirla, podría ser:

• Facturación y Gestión de riesgos.
• Informes y estadísticas de Venta.

El ejemplo que he dejado en DEMO tiene 2 aplicaciones y lo que quiero mostrar es cómo desde una aplicación se conecta a otra, manteniendo el usuario y cambiando de perfiles/grupos, de acuerdo a cada aplicación.

El ejemplo es sencillísimo.

Evento (After successful login):

$_SESSION['app'] = 'app2';
$_SESSION['login'] = $username;

Guardo en variables de sesión la aplicación y el login del usuario.

Evento (After application initialized):

// Control new user form other APP
if (isset($_SESSION['app']) and  $_SESSION['app'] <> 'app2') { 
    $user = $_SESSION['login'];
    Security::logout();
    Security::loginAs($user, $callEvent = true); // lOGIN new user
}

Controla que si el usuario conectado tiene una aplicación distinta a la que se está ejecutando, cierra la identificación y vuelve a conectarse en esta aplicación.

Configuración para que se acceda a las variables de sesión entre las aplicaciones.

Para que este sistema funcione es requerido:

• Que la tabla de usuarios sea compartida para todas las aplicaciones.
• Que todas las aplicaciones interconectadas funcionen en el mismo dominio (por simplificar, un único servidor web), para que las sesiones de las distintas aplicaciones se compartan y se pueda acceder.
• No es necesario que sea un único esquema de base de datos, pero si no es muy, muy grande (más de 300 tablas) puede ser una ventaja que se comparta el esquema de la base de datos.

Nada más que esto es lo importante para ir de una aplicación a otra.

Ventajas de dividir aplicaciones en módulos:

• Mucho más fácil de entender, comprender y solucionar.
• Se puede dividir los trabajos más fácilmente en el quipo de desarrollo.
• Se puede establecer diferentes versiones de PHP, etc., por requisitos de librerías u obsolescencia de algún módulo.
• Menos riesgos en actualizaciones de aplicaciones porque los cambios son más controlados. Menor carga en pruebas de aplicativo ante las actualizaciones.

2.- La librerías externas, ubicarlas fuera del proyecto de PHPRunner.

Esto lo he utilizado en muchos de mis ejemplos, pero hay uno en especial, muy consultado que tiene este criterio: Crear factura en Word, Excel o PDF y enviar Email

Podréis ver que el conjunto de librerías externa son 34MB de  miles de ficheros y que están en un directorio externo que he llamado “ComponentCode“.

Esto ahorra muchísimo tiempo en la creación del aplicativo y también en las subidas de los desarrollos a producción.

3.- Trabajo de varios desarrolladores en el proyecto.

Ya hemos visto que al dividir en módulos, se puede repartir mucho mejor los trabajos en el equipo de trabajo.

Si son varios desarrolladores trabajando en un único Módulo, lo que he hecho es que uno se dedica a los trabajos “simples” y otro trabaja en las partes difíciles, desarrollando e integrando librerías externas o simplemente, haciendo explotaciones de informes y gráficos.

Una de las opciones que falta y que entiendo va a disponer (no sé en que fase del desarrollo de la versión 11 de PHPRunner), es la posibilidad de copiar definiciones y código de un proyecto a otro.

Mientras esta posibilidad no se tenga, lo que hago es escribir los códigos o personalización de los eventos de PHP en ficheros del apartado “Custom File” que suelo crear un directorio llamado “MyCode” y en los eventos  lo que hago es include “MyCode/file……php”, de esta forma pasar código de una aplicación a otra es muy sencillo ya que es pasar este tipo de ficheros y hacer los includes.

De esta forma se avanza muchísimo y se pueden dividir las tareas y posteriormente integrarlas en un único proyecto de PHPRunner.

Esta forma de construcción también me da más facilidades de escribir y depurar el código con las soluciones que ya os he contado:

• Guía 22 –  Depuración código PHP, línea a línea. Utilización de NetBeans for PHP.
• Guía 34 – Método básico para la depuración de código – DEBUG

Es muy probable que os surjan dudas porque alguno de los conceptos que he intentado explicar no lo haya explicado bien o por el simple problema del idioma que he utilizado. Para cualquier duda o necesidad, podéis contactar conmigo a través de mi email: [email protected]

Como es habitual, os dejo los fuentes del ejemplo para que lo podáis instalar en vuestros PC’s y hagáis los cambios que consideréis oportunos.