Desarrollo web empresarial con PHP4
PARTE 1
Autor: Diego Mauricio Paz Carrillo
Fecha: Julio 26 de 2.005
Nivel: Medio
Categoría: Aplicaciones Web
Licencia: Creative Commons Attribution-NonCommercial-ShareAlike License
Versión en XML-DocBook:
Contenido |
Introducción
Hoy en día, cerca de 20 millones de dominios han sido implementados utilizando la plataforma de desarrollo PHP. Gran parte de ellos son sitios web para la pequeña y mediana empresa.
Cuando se comienza en el mundo de PHP, se encuentra una plataforma desarrollo que brinda una oportunidad de aprendizaje única, en donde los conceptos básicos de desarrollo de páginas web dinámicas se digieren en tiempos relativamente cortos. Ésta es quizás, la razón por la cual PHP es popular: la gente busca practicidad, lenguajes fáciles de entender y que de cierta manera den "resultados de corto plazo".
Pero todo lo anterior ha ido convirtiéndose paulatinamente en el principal enemigo de los productos software basados en PHP, lo cual se hace notorio cuando encontramos desarrollos web en los cuales no se utiliza ningún criterio de orden, ni de reutilización, ni de LÓGICA; desarrollos sin diseño, ni análisis, ni arquitectura que pasan por alto la escalabilidad, la documentación, la manipulación de errores, la internacionalización, etc.
Es así, como se ha popularizado la creencia que PHP es un lenguaje "para novatos" o simplemente un lenguaje “para hacer aplicaciones web de pequeña y mediana escala”. Y no es para menos, ya que el código de bajo nivel técnico abunda en los repositorios de software de la Internet. Y si a esto le agregamos la cantidad de proyectos GPL que facilitan la construcción de sitios, pero que en cierta medida redundan en características inútiles y poco llamativas para la industria de la computación empresarial, podríamos llegar a la somera conclusión que “en algo tienen razón”.
La industria que requiere desarrollo de software a la medida en muchas ocasiones exige que los derechos morales y patrimoniales del código fuente de la solución sean cedidos, razón por la cual, una solución que se encuentre licenciada bajo la licencia GNU/GPL puede generar contradicciones legales. No obstante, existen alternativas como PostgreSQL, y librerías LGPL/BSD (Como Mojavi, AdoDB, TinyButStrong) bajo las cuales se pueden generar soluciones de software empresarial independientes de los requerimientos legales del cliente.
El futuro de PHP es promisorio y basta con ver proyectos como PRADO [1] o WACT [2], para darse cuenta de la potencia de PHP5 y su evolución, al punto de ser comparable con plataformas de desarrollo empresarial como J2EE [3] o .NET [4]. Este es el primer artículo de cuatro (4) que pienso publicar, acerca de desarrollo empresarial con PHP.
Un Poco de Historia
PHP es un lenguaje dinámico e interpretado; su nombre significa "PHP: Hypertext Preprocessor" y surgió en 1995 como un conjunto de scripts de Perl llamado PHP/FI, creado por Rasmus Lerdorf, cuyo objetivo principal era manipular dinámicamente paginas web personales (originalmente, PHP significaba "Personal Home Page Tools").
En 1997, Andi Gutmans y Zeev Zuraski, reescribieron completamente PHP/FI y sacaron la primera versión de PHP, tal y como se le conoce actualmente (PHP 3.0). Esta versión de PHP se caracterizó por su extensibilidad, la cantidad de APIs con la que contó y su sintaxis potente y consistente. En esta versión de la plataforma, surge el primer soporte para programación orientada a objetos de PHP.
En Mayo de 2000 se libera lo que se llamaría el “Motor Zend”, junto con una nueva versión de PHP (PHP 4), cumpliendo los requisitos de diseño y rendimiento exigidos por el creciente mercado de las aplicaciones web. Todo esto gracias a las características heredadas de PHP 3 y a la colaboración de la comunidad de software libre a través de APIs para diferentes propósitos.
En el 2004, se libera lo que hasta la fecha es la última implementación de PHP, (PHP 5), a través del motor Zend 2, el cual añade mejoras sobre las anteriores versiones, tanto en su plataforma, como en la sintaxis de su lenguaje, agregando características como la compilación, mejor soporte para programación orientada a objetos, manejo de excepciones, nuevas funciones y nuevas directivas, entre otras.
Análisis de Requerimientos de una Aplicación Web Empresarial
A continuación se nombrarán algunos requisitos no-funcionales que debería tener una aplicación web empresarial:
- Permitir separar lógicamente las capas de dominio, control y presentación, a través del patrón de diseño Modelo-Vista-Controlador (MVC).
- Tener un motor de plantillas sencillo, pero potente, que permita una total separación del código PHP y el código HTML.
- Manejar acciones y cadenas de acciones para controlar el acceso a la lógica del negocio (Modelo).
- Tener opciones de validación para las entradas de usuario, y así evitar el comportamiento inesperado de la aplicación.
- Contar con una herramienta para manipulación de sesiones, ya sean en el disco duro del servidor, o en una base de datos.
- Permitir la autenticación de usuarios y el control de privilegios de acceso a los recursos.
- Proporcionar un sistema de gestión, despliegue y manipulación de errores y páginas de error.
- Aportar una capa de abstracción de datos, que permita mapear las consultas realizadas por la lógica del negocio en la(s) base(s) de datos
- Ofrecer herramientas para la internacionalización de la aplicación
Una visión general, de la arquitectura a implantar, basada en los requerimientos anteriormente planteados, sería así:
Este primer artículo se va a enfocar básicamente en el esquema de trabajo de la capa de dominio, es decir, la forma como se van a construir los “cimientos” de la aplicación y cómo a partir de éstos, se escalan las características adicionales y que finalmente dan “los acabados” para lograr una aplicación web lo más óptima posible.
Mojavi: The Open Source MVC-PHP Framework
Mojavi[5] es quizás, uno de los mejores esfuerzos realizados en PHP para implementar el patrón de diseño MVC sin tener que realizar innecesarias imitaciones de otros frameworks existentes y muy conocidos como Struts[6]. Es una aplicación que basa su potencialidad en la realización de soluciones de forma sencilla, basándose en un práctico modelo de trabajo.
Para entender un poco que es Mojavi, primero haremos una breve introducción a lo que es el patrón de diseño MVC.
¿Qué es un Patrón de Diseño?
Un patrón de diseño describe un problema que ocurre frecuentemente en el campo de la construcción de software y su respectiva solución; puede ser empleado muchas veces, en diferentes contextos, sin tener que duplicar el diseño. Se trata de un elemento de diseño que puede ser reutilizado.
Un patrón de diseño tiene cuatro elementos esenciales:
1. El Nombre del Patrón: Es aquel que podemos utilizar para describir el problema de diseño, sus soluciones y consecuencias en una o dos palabras.
2. El Problema: Describe cuándo aplicar el patrón. Especifica el problema y su contexto. Debe describir los problemas de diseño específicos así como su representación conceptual como objetos. En ocasiones, el problema debe incluir una lista de condiciones que se deben conocer antes de aplicarse el patrón.
3. La Solución: Describe los elementos que construyen el diseño, sus responsabilidades y colaboraciones. La solución no describe un problema de diseño en particular, porque un patrón es una especie de plantilla que puede ser aplicada en diferentes situaciones.
4. Consecuencias: Son los resultados de aplicar el patrón.
Uno de los catálogos de patrones de diseño más famosos es el realizado por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides en su libro "Design Patterns: Elements of Reusable Object-Oriented Software" [7].
El Patrón de Diseño Modelo Vista Controlador
MVC es un patrón de diseño que fue inicialmente utilizado para construir interfaces de usuario en Smalltalk-80 [8].
MVC consiste de tres tipos de objetos. El Modelo, que son los objetos de la aplicación, también conocida como lógica de negocio, o lógica de aplicación. La Vista especifica la visualización de los datos, algunas veces conocida como lógica de presentación. El controlador es el coordinador entre estos dos últimos, es decir, define la forma en que la interfaz de usuario reacciona ante la entrada de usuario. MVC desacopla el concepto de interfaz de usuario y lógica de negocio para aumentar la flexibilidad y modularidad del software, posiblemente permitiendo que el código pueda ser reutilizado.
Finalmente, la idea es lograr separar responsabilidades entre las personas que trabajan para un proyecto de desarrollo de software; es decir, descomponer el problema en módulos funcionales, (entre ellos el diseño gráfico), lo que se traduce en enfocar de una forma reduccionista la solución de un proyecto software.
Imagen extraída de http://java.sun.com/blueprints/patterns/MVC-detailed.html
Entendiendo lo anterior, se proseguirá a mostrar algunas de las características de Mojavi y cómo pueden ayudar a desarrollar aplicaciones web de una manera más profesional y robusta.
Diseño Modular El diseño modular de Mojavi permite el uso y reutilización de código fuente de otras aplicaciones. La completa separación de responsabilidades evita el código redundante y ayuda a crear aplicaciones web más escalables.
Cadenas de Filtros Esta característica permite la ejecución secuencial de varios filtros. Los filtros permiten ejecutar una acción de control, antes y/o después que una acción propiamente dicha se ejecute.
Cadenas de Acciones Permiten la ejecución de varias acciones al mismo tiempo. Una acción es la encargada de ejecutar código que se encuentra en la Lógica de Negocio de la aplicación web, la cual se encuentra encapsulada en el Modelo.
Contenedores de Usuario Personalizables Un contenedor de usuario es un objeto que guarda las características de un tipo de usuario dentro del entorno de la aplicación web. La personalización de usuarios nos permite la creación de perfiles dentro del sistema.
Validación de Parámetros Es la característica que nos garantiza que las entradas de usuario cumplan ciertos requerimientos, para evitar comportamientos inesperados de la aplicación. La validación también puede modificar la entrada de datos, antes de ser ejecutada por la lógica de negocio.
Librería de Validadores La librería de validadores nos proporciona una serie de herramientas para validar entradas como correos electrónicos, tarjetas de crédito, mediante expresiones regulares. Esta librería es bastante útil al momento de validar formularios del lado del servidor.
Sistema de autenticación y autorización Esta característica nos ayuda a autenticar y a autorizar a un usuario dentro de la aplicación dependiendo de su contenedor de usuario. Esto evita el engorroso proceso de manipulación y gestión de sesiones cuando un usuario se autentica.
Manejo de Errores y Logs El manejo de errores es algo muy importante dentro de cualquier aplicación web, ya que ayuda tanto al desarrollador como al usuario a ubicarse cuando una advertencia o excepción ha ocurrido en la aplicación web. Es definitivo, que el gestor de errores provisto por defecto en PHP puede ser insuficiente, especialmente si se está hablando de una aplicación donde pueden ocurrir otro tipo de errores diferentes a los sintácticos o de análisis, comunes del depurador PHP.
Arquitectura de Mojavi2
A continuación, se observarán las características básicas de la arquitectura del núcleo de Mojavi2.
Como se puede ver, el núcleo (o core) del framework se encuentra en la carpeta lib, donde están las clases esenciales para el correcto funcionamiento de la aplicación web. La siguiente gráfica es útil para aclarar un poco el funcionamiento de las clases del núcleo de Mojavi:
CLASES DEL NÚCLEO
Controller: Es la clase encargada de despachar las peticiones por el usuario a la acción correspondiente dentro del flujo de la aplicación. Esta clase utiliza el patrón de diseño Singleton[9] para su instanciación.
Action: Es una clase abstracta que se encarga de ejecutar el código residente en la lógica de negocio de la aplicación. Es una clase que implementa el patrón de diseño Abstract Factory [10].
View: Es la clase abstracta que se encarga de representar la vista del sistema y cómo se deben mostrar los datos que provienen de la capa de dominio.
Request: Es la clase cuyos objetos se encargan de encapsular los datos provenientes de la entrada de datos HTTP del usuario.
User: Clase que provee las características para manipulación de los atributos del usuario a través de la aplicación web.
Renderer: Es la clase que, en colaboración con una vista, realiza la presentación de los datos, a través de un archivo de plantilla.
Validator: Es la clase abstracta que provee las funciones principales que debe tener la librería de validadores.
ValidatorManager: Es la clase encargada de gestionar y automatizar el proceso de validación.
ExecutionChain: Permite la ejecución de varias acciones a través de una misma petición.
ActionChain: Clase que provee la funcionalidad de ejecutar varias acciones al mismo tiempo.
CLASES DE LA SUBCARPETA FILTERS
Filter: Esta clase es la encargada de interceptar las peticiones y ejecutar una acción previa y/o posterior a la ejecución de un objeto Action.
ExecutionFilter: Es una clase que se extiende de Filter, y es la encargada de controlar la validación, la ejecución de una acción y la presentación de la vista.
FilterList: Clase que permite registrar una lista de filtros en un determinado orden.
FilterChain: Clase que controla la ejecución de los filtros.
CLASES DE LA SUBCARPETA LOGGING
Logger: Clase que provee la interfaz para enviar logs a los diferentes agregadores (Appenders).
LogManager: Es la clase encargada de administrar todos los generadores de logs.
Message: Los objetos de esta clase contienen la información acerca de un mensaje de log.
Appender: Es el encargado de redireccionar nuestros mensajes hacia un determinado destino.
Layout: Permite personalizar la forma de representación de los datos por parte del agregador (Appender).
Hola Mundo en Mojavi2
Para el ejemplo a continuación, se va a trabajar con la versión 2.0.0 de Mojavi. La versión 2 de Mojavi viene diseñada para la versión 4 de PHP.
1. INSTALACIÓN
NOTA: Para trabajar con Mojavi2, necesitamos tener instalado (y corriendo) algún servidor web, junto con el módulo de PHP.
1.1. Descarga
Descargamos el archivo que contiene el código fuente de Mojavi 2.0.0 (Stable), de la página oficial de Mojavi http://www.mojavi.org , específicamente de http://www.mojavi.org/index.php/module/Default/action/Static/page/downloads.php
1.2. Descompresión
Descomprimos el código fuente a una carpeta que pueda ser accedida por el servidor web. Ej: El documentroot (/var/www/html).
1.3. Estructura de directorios
Una vez descomprimido el archivo, podemos ver la estructura de archivos de Mojavi, tal y como habíamos hablado con anterioridad. Se puede ver inicialmente tres carpetas: lib, opt y webapp. Lib es la carpeta donde se encuentran las clases del núcleo de Mojavi y que se encuentran incluidas en el archivo mojavi-all-classes.php. Opt es la carpeta donde se encuentran las clases complementarias que utilizan las funcionalidades provistas por la arquitectura central. Webapp es la carpeta donde vamos a poner la lógica de negocio de nuestra aplicación, es decir, los módulos.
1.4. Configuración de Mojavi
A continuación configuramos Mojavi por medio del archivo webapp/config.php, de la siguiente manera:
Suponiendo que nuestra aplicación se llama “aplicación”, definimos la variable BASE_DIR así:
<php> define('BASE_DIR', '/var/www/html/aplicacion/webapp/'); </php>
NOTA: Hay que tener cuidado en que la ruta absoluta suministrada, termine con slash (trailing slash).
Definimos la variable MOJAVI_FILE asi:
<php> define('MOJAVI_FILE', '/var/www/html/aplicacion/mojavi-all-classes.php'); </php>
NOTA: El archivo mojavi-all-classes.php es el archivo más importante de Mojavi, ya que es en éste donde se encuentra el núcleo de la arquitectura (Las clases de la carpeta lib en un sólo archivo).
Definimos la variable OPT_DIR asi:
<php> define('OPT_DIR', '/var/www/html/aplicacion/opt/'); </php>
Definimos las variables SCRIPT_PATH y BASE_PATH asi:
<php> define('BASE_PATH', 'http://localhost/aplicacion/'); define('SCRIPT_PATH', BASE_PATH . 'index.php'); </php>
NOTA: Sobra la advertencia, pero no hay que olvidar que “localhost” se utiliza únicamente por razones de prueba en la máquina local.
Esta es la configuración mínima para poner a funcionar el framework, pero es bueno leer y ENTENDER el resto de variables y su función en la aplicación.
1.5. Configuración del archivo index.php
Para configurar el archivo index.php, simplemente tendremos que requerir el archivo de configuración de Mojavi a través de la siguiente línea
<php>
require_once('webapp/config.php');
</php>
y comentar la línea siguiente:
<php>
- die('Please configure your Mojavi installation and remove this line from index.php.');
</php>
NOTA: Se recomienda leer el archivo index.php con detenimiento, ya que es en éste donde se realizan cada uno de los pasos que ejecuta la aplicación.
1.6. Creando nuestra primera acción
Ahora, procedemos a crear nuestra primera acción con Mojavi, para lo cual nos ubicamos en la carpeta webapp/modules/Default/actions
NOTA: Como nosotros cargamos por defecto el módulo Default en el archivo config.php, vamos a trabajar con éste. En caso que se quiera crear un nuevo módulo, basta con crear una nueva carpeta dentro de webapp/modules con el nombre del módulo a implementar. Los módulos y las acciones se acceden por medio de las entradas de usuario module y action, las cuales pueden ser personalizadas en el archivo de configuración webapp/config.php por medio de la edición de los accesors.
Creamos el archivo webapp/modules/Default/actions/DefaultIndexAction.class.php con el siguiente contenido:
<php>
<?php class DefaultIndexAction extends Action {
function getDefaultView (&$controller, &$request, &$user)
{
return VIEW_SUCCESS;
}
function getRequestMethods ()
{
return REQ_NONE;
}
} ?>
</php>
Lo que hace esta clase es extender la clase abstracta Action e implementar la función getDefaultView() para obtener la vista por defecto, que en este caso sería SUCCESS. En Mojavi, existen seis (6) tipos de vista que son: SUCCESS (Éxito), ERROR (Error), INPUT (Entrada), ALERT(Advertencia), INDEX (Indice) y NONE (Ninguna).
También en la acción definimos la función getRequestMethods(), la cual nos define, el tipo de petición que va a procesar la acción, estas peticiones pueden ser REQ_NONE (Ninguna), REQ_POST (Post) y/o REQ_GET (Get). Para el ejemplo anterior, pusimos REQ_NONE, porque no vamos a procesar peticiones.
NOTA: Existen otras funciones a implementar en una acción de mojavi, como execute(&$controller, &$request, &$user), getPrivilege(&$controller, &$request, &$user), handleError(&$controller, &$request, &$user), isSecure(), registerValidators(&$validatorManager, &$controller, &$request,&$user) y validate(&$controller, &$request, &$user), las cuales serán explicadas en el siguiente artículo.
1.7. Creando la vista para la acción
Como vimos, la acción anterior ejecuta la vista DefaultIndexView_success por lo que debemos crear el archivo webapp/modules/Default/views/DefaultIndexView_success.class.php en la carpeta views del módulo, con el siguiente contenido:
<php> <?php class DefaultIndexView extends View {
function & execute (&$controller, &$request, &$user)
{
$renderer =& new Renderer($controller, $request, $user);
$renderer->setTemplate('plantilla.php');
return $renderer;
}
} ?> </php>
Esta clase simplemente ejecuta una actividad, teniendo en cuenta las instancias del controlador, la petición y el usuario, lo que requiere de la instanciación de la clase Renderer y la ejecución de la función setTemplate(), que va a ser la función que nos va a permitir establecer la plantilla a utilizar.
1.8. Creando la plantilla para la vista
Y para finalizar nuestro primer ejemplo, creamos la plantilla webapp/modules/Default/templates/plantilla.php en la carpeta templates con el siguiente contenido:
<php>
Hola Mundo
</php>
A continuación probamos en nuestro navegador la página http://localhost/aplicacion/ y debe salir algo como esto:
<php> Hola Mundo </php>
PARA FINALIZAR
En este primer artículo (de 4 que pienso publicar) hemos abarcado un poco lo que es la parte MVC de nuestra arquitectura web. En el próximo profundizaremos en los modelos de datos con Mojavi, manejo de cadenas de acciones y vamos a construir un módulo para autenticación de usuarios.
En el tercer artículo pienso trabajar un poco lo que es el Motor de Plantillas, y cómo crear nuestra propia clase para manipularlas desde Mojavi. Igualmente, con la aplicación que nos va a servir como capa de abstracción de datos.
En el último artículo, pienso hablar acerca del proyecto Artemis, de cómo integra cada uno de los conceptos vistos y su arquitectura.
Bibliografía
[1] Página Web Oficial del Proyecto Prado
[2] Página Web Oficial del Proyecto WACT
[3] Página Web Oficial de la Plataforma J2EE
[4] Página Web Oficial de la Plataforma .NET
[5] Página Web Oficial del Proyecto Mojavi
[6] Página Web Oficial de Jakarta Struts
[7] GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements of Reusable Object-Oriented Software. 1998. Addison Wesley Longman Inc.
[8] Smalltalk, en la Wikipedia
