El blog de HAL

OpenGoo es una Interesante alternativa de código abierto para las aplicaciones de oficina convencionales ya que es implementado totalmente sobre la Web.

Según dice en el sitio oficial, está contruido bajo dos estrategias

• Aprovechamiento de los Mashup, lo cual implica que hacen uso de otros proyectos opensource para desarrollar herramientas mas fáilmente, integrarlas e implementarlas en un Look & Feel de una única aplicación.
• El equipo solo desarrolla nuevas piezas de software cuando las alternativas opensource no los convencen. Actualmente este trabajo se está realizando haciendo uso de Java/JEE.

El el sitio oficial ofrecen un enlace para una versión Demo que vale la pena evaluar.

En los últimos artículos que he escrito y que incluyen necesariamente código HTML que no pretendo que sea interpretado por el Navegador, sino que sea vea justamente como eso (Código HTML), me ha dolido la cabeza mas de una vez al ver que al agregarlo a través de WYSIWYG en la vista de diseño, este lo interpreta como HTML, por ende no se visualiza.

La medicina para esto se encuentra en este sitio:

http://www.simplebits.com/cgi-bin/simplecode.pl

Básicamente lo que tenemso que hacer es pegar nuestro código HTML en el primer cajó, presionar el botón "Process" y obtendremos nuestro código pero como sus respectivas traducciones de sínbolos a ASCII, el cual pegaremos en Blogger en la vista de código, así nuestro código podrá ser visto como lo queremos.

Via mgnt.es me entero de un nuevo theme para Magento lanzado por la gnete de Varien, al parecer mas Interesante desde el punto de vista de los desarrolladores.

http://www.mgnt.es/2008/09/17/blank-theme-para-magento/

Frustraciones como el no poder correr un juego que he tardado tiempo en conseguir o en su defecto descargar, son las que a veces hacen que sienta perdido mi tiempo.

Hace ya unos meses mientras buscaba a cerca de videojuegos me surgió la inquietud de si este podría correr en mi PC que tampoco es la maravilla, así que encontré este sitio http://www.systemrequirementslab.com/ que me indicó si el juego que pretendia descargar podria ser utilizado en mi PC.

Muy util, y hoy que lo he vuelto a encontrar lo quiero compartir con ustedes, solo hay que especificar unos datos mediante selección y obtendremos nuestra respuesta.

http://www.systemrequirementslab.com/

EA está celebrando 13 deaños de historia del Juego Red Alert y para celebrarlo con todos, ha puesto en descarga directa y totalmente gratuito el Juego RedAlert, con esta iniciativa pretenden lanzar además la versión 3 de la saga la cual también viene con regalo, ya que si la compramos, nos regalan la versión 2 :-).

Mas información en el siguiente enlace

http://www.ea.com/redalert/news-detail.jsp?id=62

Esta es una traducción de la serie de artículos publicados en http://blog.astrumfutura.com, no representa una traducción oficial, sino un trabajo voluntario para darlo a conocer en nuestro idioma.

Es casi obligatorio cuando se llega a un nuevo tema en programación, que el autor presente el ejemplo mas simple posible. por lo general, esto significa hacer uso de un lenguaje de programación o Framework para imprimir "Hola Mundo" en la pantalla. No voy a ser diferente. Esto en cuanto a originalidad...

Anteriormente: Parte 2 - La arquitectura MVC de la aplicación


Paso 1: Creando una nueva aplicación

Antes de saltar a la programación con el Zend Framework hay algunas tareas de configuración. Necesitamos instalar el Zend Framework, obtener un dominio virtual en funcionamiento, y tener una colección básica de directorios y archivos en blanco creados para adherirse a nuestro código fuente.

Para ello necesitará descargar el Zend Framework 1.5.3 (Reciente liberación) de http://framework.zend.com y pongalo en algún lugar de su ruta de includes (inclusión). Trato de minimizar el número de rutas de includes y no acabar teniendo que escoger rutas extrañas (como el directorio PEAR que por lo general ya se encuentra en el include_path) u otra ubicación central de librerías como PEAR donde podría tener una docena de librerias reunidas.

Una solución común encontrada en Blogs y Artículos es poner el framework dentro del directorio "library" que estaría ubicado dentro del directorio "application" en el árbol de directorios. Por lo general no recomiendo esto a menos que su aplicación necesite una versión específica de Zend Framework - Una ubicación centralizada del Zend Framework para que múltiples aplicaciones puedan accederla, puede hacer el mantenimiento un poco mas fácil.

Me he decidido por usar un host virtual, principalmente porque es fácil de instalar y ayuda a evitar algunos molestos temas de rutas base que se obtienen en su HTML cuando se usa mod_rewrite para urls accesibles - especialmente en el desarrollo donde, en caso contrariom la raiz de documentos de localhost se convierte en una masa de subdirectorios sobre subdirectorios que acaban causando problemas de tipo href muy fácilmente. Por lo general abro el archivo virtual-host.conf desde el directorio conf de Apache y añado algo así:


NameVirtualHost ∗:80



<VirtualHost ∗:80>

DocumentRoot “/path/to/htdocs”

ServerName localhost

</VirtualHost>



<VirtualHost ∗:80>

ServerName zfblog

DocumentRoot “/path/to/project/trunk/public”

</VirtualHost>



Esto debería dar lugar a que todas las consultas HTTP para http://zfblog/ lleguen a la raiz de documentos seleccionado (que es el directorio público para el proyecto, que contiene a index.php, ubicado en nuestra copia de trabajo con subversion en el directorio "trunk"). Vamos a crear esta estructura de directorios mas tarde. Por lo general también necesitamos referenciar a localhost para asegurar su reconocimiento por paerte del host de forma correcta - de lo contrario cualquier direccionamiento a localhost que ya haya hecho de repente serán desviados a la raiz de documentos de zfblog misteriosamente ;-).

Para aquellos de ustedes que están Windows XP o vista, también tendrán que añadir el nuevo dominio virtual a su archivo de hosts (normalmente C:\WINNTsystem32\drivers\etc\hosts). Esto es un tanto mas dificil en Vista - Probablemente necesitará  modificar el archivo de los permisos de los archivos usando una cuenta de Administrador para garantizarle al usuario local privilegios adicionales para modificar. ¡Asegurese de revertir los privilegios después! de Editar a solo Ver.

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

127.0.0.1 localhost

127.0.0.1 zfblog

Reinicie su servidor y con un poco de suerte, verá en el navegador un listado de directorios (Una vez añada el directorio raiz "public" como se muestra mas abajo).

La parte menos interesante es la creación de un árbol de directorios para contener nuestro código fuente. Wil Sinclair a lo largo de Zend está trabajando en un componente Zend_Build que seguramente algún dia eliminará la repetición en la creación de estos directorios y archivos por defecto. Hasta entonces, dejemos seguir a la monotonia (o mantenga un esqueleto a mano para poder copiar y pegar ;-) ).

He aquí una imágen del ejemplo Hola Mundo y como se observa la vista de directorios desde Eclipse:



Copie y cree la misma estructura de durectorios en un nuevo directorio llamandolo como usted prefiera, en este caso lo llamaremos "zfblog". Si quieres poner todo en el "trunk", es opcional - Aquí he usado subversion, esa es la razón por la que existe el directorio "trunk". Si no ha llegado a usar Subversion antes, le sugiero que aprenda un poco mas de esta herramienta, es altamente recomendado su uso, además es simple de aprender y usar.

Vamos a revisar brevemente cada uno de estos directorios.

El directorio "application" es donde ubicamos todos los componentes donde una aplicación implementa el Modelo-Vista-Controlador. Dentro de "application" encontramos a , "controllers", "models" y "views" que representan las ubicaciones respectivas  para el controlador, el modelo  y la vista de código fuente y plantillas. Dentro de "Views" hay una subdivisión entre "filters", "helpers", "layouts" y "scripts". Por ahora, recuerde que nosotros ponemos todos los templates renderizados por la vista en "scripts". En la captura de pantalla, vemos un directorio index que contiene un archivo index.phtml, que es el template de la vista para indexAction de una clase IndexController. los demas los conoceremos luego.

El directorio "modules" es también para controladores, modelos y vistas, pero en este caso son categorizados dentro de múltiples divisiones de una aplicación. Si lo piensas, veras que en una aplicación pueden estar separados en varias partes, por ejemplo la aplicación principal y una parte de administración. La sección de administración podria estar separada dentro del Módulo Admin por lo tanto no está entremezclada con la aplicación principal.

Existe un archivo Bootstrap.php en el directorio "application" que representa  un clase llamada "Boostrap". Su propósito es inicializar el Zend Framework, ajustar las preferencias del entorno (por ejemplo, la zona horaria y el nivel del error_reporting), y por otro lado realiza ajustes y adiciones específicas a la aplicación antes de procesar una petición por HTTP. Muchos tutoriales usan otra alternativa de vista y ponen el código del Boostrap dentro del código de index.php. Le recomiendo evitar este método y usar una clase real para organizar el código del Bootstrap - esto hace que sea mucho mas fácil de leer ¡si no hay nada mas!.

El directorio "config" simplemente tiene los datos de configuración para la aplicación, por ejemplo, los detalles de la conexión a la base de datos.

El directorio "library" puede tener una copia del Zend Framework. Generalmente evito esto ya que es mucho mas fácil agregar el Zend Framework al include_path de PHP. pero sin embargo lo anterior es muy útil si quiere cambiar la versión del Zend Framework para un uso mas flexible. también es muy útil si lo usa para añadir un referencia svn:external al repositorio subversion del Zend Framework.

El directorio "public" tiene todos los arcivos accesibles por una petición al servidor web. este directorio incluye un archivo index.php que se ocupa de todas las peticiones de la aplicación llamando a la case Bootstrap, así como cualquier archivo CSS, HTML javascript etc...

Una nota sobre el despliegue en la práctica: en general, en el despliegue usted mueve el directorio "public" a su servidor web para que sea accesible sobre Internet, pero mantiene los directorios no públicos dentro del directorio raiz del sitio.  ya que index.php termina haciendo una simple referencia al archivo Bootstrap.php incluyendolo, significa que muchos de los archivos de la aplicación no serán accesibles por los usuarios de Internet. También significa que el archivo index.php terminará decidiendo donde está ubicado el archivo Bootstrap - por lo tanto es el único archivo que siempre necesitará ser editado a mano para el despliegue y cambiar esa ubicación según sea necesario.

El directorio "test" normalmente tiene cualquier aplicacion específica de unidad, especificación y pruebas de aceptación. Como lo dije anteriormente, estoy tomando deliberadamente un enfoque test-light para permanecer sobre el tema (Tengo mas de un articulo de prueba/desarrollo en el Zend DevZone en el caso que esté interesado en aplicar TDD o BDD). Las pruebas principales que espero tener son para las clases específicas de la aplicación: cualquier Modelo lógico por ejemplo.

Al final de este paso denería tener el directorio estructurado en un lugar conteniendo algunos archivos en blanco como los siguientes (creelos ahora, y los llenamos luego):

/application/Bootstrap.php

/application/controller/IndexController.php

/application/views/scripts/index/index.phtml

/public/index.php

/public/.htaccess

Paso 2: Implementando nuestro archivo Bootstrap.

El Bootstrapping es cuando configuramos el entorno inicial e inicalizamos el Zend Framework para nuestra aplicación. No es un archivo dificil de escribir, pero puede crecer y volverse mas complejo a medida que nuestra aplicación vaya aumentando en características. Para manejar esto es altamente recomendado implementarlo en una clase con métodos pequeños en tamaño. Para el esqueleto de nuestra aplicación Hola Mundo, /application/Bootstrap.php contiene:


require_once 'Zend/Loader.php';

class Bootstrap
{

    public static $frontController = null;
  
    public static function run()
    {
        self::setupEnvironment();
        self::prepare();
        $response = self::$frontController->dispatch();
        self::sendResponse($response);
    }
  
    public static function setupEnvironment()
    {
        error_reporting(E_ALL|E_STRICT);
        ini_set('display_errors', true);
        date_default_timezone_set('Europe/London');
    }
  
    public static function prepare()
    {
        self::setupFrontController();
        self::setupView();
    }
  
    public static function setupFrontController()
    {
        Zend_Loader::registerAutoload();
        self::$frontController = Zend_Controller_Front::getInstance();
        self::$frontController->throwExceptions();
        self::$frontController->returnResponse(true);
        self::$frontController->setControllerDirectory(
            dirname(__FILE__) . '/controllers'
        );
    }
  
    public static function setupView()
    {
        $view = new Zend_View;
        $view->setEncoding('UTF-8');
        $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
        Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
    }
  
    public static function sendResponse(Zend_Controller_Response_Http $response)
    {
        $response->setHeader('Content-Type', 'text/html; charset=UTF-8', true);
        $response->sendResponse();
    }

}


La clase Bootstrap tiene dos métodos principales aquí: run() y prepare(). run() ejecuta una petición completa a la aplicación, mientras que prepare() solo establece (pero no ejecuta) el Front Controller. Por ahora enfoquemonos en run() y todos los pasos que nuestro Bootstrap realiza cuando es llamado, El método prepare() es el que uso cuando aplico TDD o BDD para el desarrollo de los controladores, ya que delega la ejecución del controlador al framework de pruebas.

Los primero es configurar el entorno local. Así que aquí hemos establecido una zona horaria (Según lo requiera PHP), habilitar  la opción display_errors de PHP.  un establecer un error bastante  rigido a nivel de información. Si poniendo lo básico dentro de una clase parece poco intuitivo, puede simplemente extraerlo a la cabecera del archivo. Y que por lo general lo pruebo bastante, normalmente no los quiero corriendo durante mis pruebas e interfiriendo con los resultados de las pruebas.

En segundo lugar, preparamos el Front Controller. Zend _Controller es una implementación del patrón de diseño Front Controller, que actua como un único punto de entrada a una aplicación de arquitectura Modelo-Vista-Controlador. Cada petición que no es para un archivo público existente para a través de él. En nuestro caso, ya que el Bootstrap esta incluido dentro y es llamado por public/index.php, "index.php" es nuestro único punto de entrada.

En este sentido, la fase de prepare() involucra la creación del Front Controller:
- Ontiene una instancia del Zend_Controller_Front
- Configurarlo para que capture todas las excepciones (Talvez quiera desactivarlo cuando se encuentre en producción).
- Configurarlo para que devuelva un objeto Response en caso de envio.
Indicarle donde encontrar los controladores por defecto.

El último paso de prepare() hace algunos cambios a la vista. La razón por la que he hecho esto es para mostrar como hacer un cambio muy común - agregando soporte para la salida codificada en UTF-8. No te preocupes demasiado por los detalles ahora - El Action Helper ViewRenderer y el Helper Broker permite añadir o modificar los Action Helpers y está bien abarcado por Matthew Weier O’Phinney en el Zend Devzone - http://devzone.zend.com/article/3350-Action-Helpers-in-Zend-Framework.

Ahora, ¿Que pasa con /public/index.php?


En si mismo Simplicidad! El Index es nuestro único punto de entrada del Front Controller dentro de una aplicación en Zend Framework, y todo lo que necesitamos determinar es un include_path válido para la aplicación y delegar todas las tareas al método run() de la clase Bootstrap.

El paso final es el cómo hacer que todas las solicitudes de "http://zfblog/" pasen a través de index.php. Esto es solucionado por los servidores Apache usando módulo Rewrite, que simplemente toma la URL de una petición entrante y la re-escribe apuntando a index.php. Si nunca ha usado el Rewrite de Apache, probablemente necesite habilitarlo en el htttp.cond antes de que funcione. Las reglas de re-escritura pueden ser definidas en el archivo http.conf de Apache o simplemente usando un archivo .htaccess en el directorio "public" que contenga las reglas:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule .∗ index.php

El archivo .htaccess de aquí, primero habilita la re-escritura, y luego especifica las reglas. Las reglas de aquí mapean todas las peticiones a index.php, a menos que se refieran a un archivo que existe en el servidor (es decir, no va a reescribir la URL a CSS, Javascript o archivos de imagen).


Paso 4: Implementando el Index Controller

Antes de continuar, unas breves palabras sobre la relación Controlador/Vista. Algún tiempo atrás se decidió hacer interpretación automatizada en el modo por defecto del Zend Framework. Esto significa que el Controlador raramente necesita una intervención manual para interpretar la Vista - en vez de eso un Action Helper llamado ViewRenderer (que deberia sonar familiar ya que lo usamos para agregar la codificación UTF-8 en nuestro Bootstrap)es llamado. Este Helper localiza una vista que coincida con el nombre del controlador y acción actual, automáticamente lo interpreta. Existen distintas maneras de desactivar esta interpretación automatizada tal como se documenta en el manual - que a menudo es útil cuando se quiere eludir al Zend_View.

Si la URL de una solicitud enviada a la aplicación en Zend Framework no contiene un controlador o acción de referencia, el Zend Framework usa el valor por defecto "index". Puesto que sólo intentamos hacer solicitud a la raiz del URL "hhtp://zfblog", necesitaremos un IndexController que contenga un Index Action. ¡Vamos a crear una!.

Agregue un archivo llamado "IndexController.php" en application/controllers conteniendo:



Todos los controladores deben extender de Zend_Controller_Action, ya que contiene todas las referencias internas a métodos y propiedades comunes a todos los controladores. Si necesita ajustar el controllador básico para agregar nuevos métodos o propiedades puede hacerlo utilizando una subclase de Zend_Controller_Action y luego hacer que todos los controladores de la aplicación extiendan de esta subclase en lugar de la original. Tenga mucho cuidado sin embargo al ahcer subclases de esta forma - es útil para añadir nuevas propiedades a la clase, pero otros métodos adicionales a menudo es mejor añadirlos como Action Helpers discretos.

Nuestro nuevo método Action hace caso omiso de la presentación; se  hace automáticamente tal como se describe anteriormente. Todo lo que necesitamos es establecer la vista de datos que necesitamos. Puede añadir casi cualquier cosa a la vista, ya que convierte una propiedad en una Vista de plantilla. Por lo tanto, sientase libre de añadir objetos y matrices. Si se utiliza Smaty o PHPTAL, esto podría ser diferente.

Arriba dijimos que la Vista en los templates podría referirse a una variabel título y darle un valor de "Hola, Mundo". Una vez que el método de acción se realiza, el ViewRenderer lo lanza e intenta interpretar un template ubicado en '/ruta/a/la/aplicacion/views/scripts/index/index.phtml'.

¿Y que es el uso de un controlador sin una Vista para desplegar?


Paso5: Implementando la vista para indexController::indexAction()

Por defecto, el Zend Framework o mas específicamente el ViewRenderer Action Helper, tratará de interpretar un plantilla para todos los Action Controller usando una convención simple, Por ejemplo, la plantilla para IndexController::indexAction() debería estar ubicada en ""/index/index.phptml" dentro del subdirectorio "scripts" de "views".

El componente Zend_View es reponsable de interpretar todas las palntillas de la vista, a menudo con un poco de ayuda (Ejemplo: ViewRenderer o Zend_Layout) desde el controlador. Una plantilla de Zend_View es HTML (o algún otro tipo de salida) intercalados con PHP y no se utiliza un lenguaje separado de etiquetas como el motor de plantillas Smarty.. Aquí hay algo para poner dentro de su archivo index.phtml para nuestra primera aplicación en Zend Framework.



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

    <meta http-equiv="Content-Type" content="text/html; charset="utf-8″ />

    <meta name="language" content="en" />

    <title><?php echo $this->escape($this->title) ?></title>

</head>

<body>

    <p>Hola, Mundo!</p>

</body>

</html>


Como puede ver, es casi puro HTML con solo PHP para la inclusión de títulos de texto (Que fijamos desde nuestro anterior método indexAction()). Para garantizar la seguridad contrar Cross Site Scripting (XSS) debemos escapar todas las salidas desde dentro de la aplicación, y Zend_View usa la función de php htmlspecialchars() desde su método Zend_View::escape(). otra meción es que, ya que configuramos nuestra Vista para usar codificación UTF-8, esta codificación también es pasada dentro de htmlspecialchars().

Si se utiliza escape() por todas partes, suena mal - bien, así es, y no lo es. Es un dolor de cabeza ya que es algo que obviamente podría beneficiarse desde la automatización - porl o tanto no aplicar el escape es la excepción por defecto. Por otra parte, debe hacerse en todo momento por lo que si ve una variable haciendo echo y que no esté rodeada por el método escape() debería proceder con cuidado.


Paso 6: Funciona?

Vaya y abra el navegador, la URL base de http://zfblog/ ahora deberia retornar un documento HTML conteniendo "Hola. mundo!"


Conclusión

Obtuvimos un ejemplo simple, corriendo y funcionando qie nos proporcionó algunos conocimientos. Pero no baje la guardia todavía. Al igual que cualquier plan de batalla, no va a sobrevivir el primer contacto con el enemigo (El Blog de Maugrim Marvellous es demasiado malo ;-) ). A medida que avancemos, es mas que probable que en contremos algunos erores a nuestro enfoque, y nuestro Bootstrap necesitará expandirse para ser mas mantenible y ni siquiera hemos estudiado Zend_Db todavía!.

Es un comienzo, si tiene suerte, pueden ser muchos incios ya que puede reutilizar un esqueleto básico similiar para saltarse toda esta tarea configuración para otros poryectos en Zend Framework.

Nota: el código fuente para esta entrada está disponible para navegar o hacer un checkout con subversion, desde http://svn.astrumfutura.org/zfblog/tags/Part3. El cçodigo compelto para la aplicación completa (tal como existe hasta el momento) se encuentra en http://svn.astrumfutura.org/zfblog.

Buscando buenos textos para documentar experiencias con Zend Framework, me encuentro con una serie de artículos muy buenos para practicar, los textos originales se encuentran en inglés y para desgracia nuestra, el blog que los contenia (http://blog.astrumfutura.com) ya no existe, así que estoy haciendo un barrido por Internet para poder recopilarlos de nuevo, a medida que los voy probando para asegurar compatibilidad con la mas reciente versión del ZF.

Parte 2: Esta si estaba en inglés, entonces a traducir, o al menos hare lo que se pueda, cualquier corrección estará bien recibida. :)



Si está esperando a que el código fuente aparezca (Yo diria, esta en el lugar equivocado jejeje), esto solo sucederá en la próxima entrega.

Anteriormente: Parte 1 Introducción y planificación

Después de hablar con varios usuarios acerca de como empezar con un framework, encontré que muchos no tienen un conocimiento avanzado de lo que denominariamos "piedra angular" de un framework para aplicaciones web hoy en dia, hablo de: El patrón de diseño Modelo-Vista-Controlador, así que vamos a saber mas sobre él, y primero, empezamos buscando en PHP.

Como antecendentes, considere el tradicional y todavia popular enfoque para escribir una aplicación en PHP. Por lo general tomas un enfoque llamado "el controlador de la página". Cada HTML de su aplicación puede tener su propio archivo PHP dedicado - a menudo esto termina en muchas páginas HTML por archivo PHP, pero solo si esas páginas son lo suficientemente similares (e.j: formularios y procesamiento del formulario son tipicos) tal que la relación está formada fuera de la necesidad de reutilizar el código en el mismo archivo. Con frecuencia, estas páginas comparten una colección de funciones, clases y constantes, Por jemplo, todas las páginas podrian neceistar Smarty, o una conexión a una base de datos o incluso quizás un modelo para recoger los datos de Usuarios, ACL, etc.

El problema es que en este escenario es muy dificil (pero no imposible) gestioanr el crecimiento y el cambio. Cada cambio y cada nueva característica requiere nuevo código. Cuando termina de poner el nuevo código, este se convierte en una enorme preocupación. Puede que necesite añadir varios cambios a varias piezas de la lógica de la aplicación, pero entonces se encuentra con que la lógica se encuentra dispersa a través de múltiples archivos PHP, Tal vez descubra que su conexión reusable a bases de datos ahora tiene sentencias SQL en 12 archivos, que ahora es necesario hacer referencia a un nuevo campo en la tabla. Puede imaginar la propagación de pequeños cambios múltiples archivos, finalmente la explosión de manera exponencial hasta que terminan en una situación donde el costo de cambio excede con mucho los beneficios. Este es el punto en que un proyecto esta simplemente estancado a pesar del entusiasmo de sus desarrolladores, y para ser claros, he caido en esa trampa anteriormente ;-). lo hecho, hecho está, descubrí el placer de la programación Orientada a Objetos y reformé mis prácticas.


El Modelo-Vista-Controlador

El patrón Modelo-Vista-Controlador (o MVC como es abreviado con frecuencia) es una solución general a la pregunta de como separar las responsabilidades en una aplicación y en ciero modo altamente estructurada. El nombre del patrón menciona las tres separaciones: Modelo, Vista y Controlador. Aunque MVCpodría parecer uno de esos conceptos esotéricos en programación, es actualmente un concepto muy simple. Usted recoge algunos trozos de funcionalidad, determina su propósito y la asigna a una de las tres separaciones y a continuación a una clase específica. Una vez que todo está dividido correctamente, termina con los pedazos pequeños que sean reutilizables, centralizados, accesibles y que encajen dentro de la construcción de bloques won un API Abstracto - trabajando ahora con APIs abstraidos hace de los cambios incrementales algo extremadamente simple (Si lo hace correctamente por supuesto ;-)). Con todo cuidadosamente organizado dentro de objetos con responsabilidades específicas el costo del cambio es reducido significativamente (Que es en realidad todo el punto que queremos cambiar para que sea barato y fácil).

Obviamente no estoy cubriendo todo el campo de la programación orientada a objetos. Pero esespero que el mensaje sea lo suficientemente claro. También la naturaleza orientada a objetos del Zend framework es en gran parte la razón por la que contiene tantos elementos. No solo tenemos el Zend_Controller - Tenemos Zend_Controller_Action, Zend_Controller_Router, Zend_ControllerFront, etc. cada rol específico o responsabilidad está cubierta por su propia clase. Esto sin duda se traduce en una abundancia de clases centradas a tal punto que puede llegar a ser dificil ver como trabajan todas las piezas - Pero honestamente, lo único que usted necesita es el API Abstraido y puede ignorar el resto a menos que realmente desee personalizar algo.

Para ser claros, el MVC es común como la suciedad, Es ampliamente utilizado en Zend Framework, Solar, Symphony, Ruby on Rails, merb, Django, Spring y un sin número de Frameworks. Se trata de un concepto para no olvidar a la hora de adoptar un framework para aplicaciones web en casi cualquier lenguaje.


El Modelo

El modelo es responsable de mantener el estado entre las peticiones HTTP y una aplicación web en PHP. Cualquier dato que debe preservarse entre las peticiones HTTP está destinado al segmento modelo de su aplicación. También incorpora las reglas y restricciones que rigen los datos, se denomina la "lógica de negocio". Por ejemplo si escribes la lógica de negocio para un modelo de órden en una aplicación para el manejo de inventarios, los controles internos de la compañia podrían dictar que órdenes de compra están sujetas a un único límite de compra en efectivo de € 500. Las compras de mas de € 500 tendrían que ser consideradas como acciones ilegales por el Modelo de órdenes (a menos que tal vez sea autorizado por alguien con una autoridad mas elevada). Por lo tanto, los modelos son el lugar lógico para el acceso a los datos, pero ta,biñen podrían actuar como una ubicación centralizada para examinar, verificar y hacer las manipulaciones finales de los datos, antes de que sean almacenados, e incluso después de ser recuperados.


La vista

La vista es la responsable de la generación de la interfaz de usuario para una aplicación. En PHP, a menudo está estrictamente definida como donde son puestos todo el HTML presentacional. Si bien esto es cierto, es también el lugar donde se peude crear un sistema de generación dinámica de HTML, RSS, XML, JSON o incluso nada mas que todo lo que va a ser enviado al navegador cliente o aplicación.

Normalmente, la vista está organizada dentro de plantillas, pero también puede ser simplemente lo devuelto por la función "echo" de php o manipulados por el controlador antes de la salida. Es esencial recordar que la Vista no es solo un formato de archivo, sino que tambien incluye todo el código PHP o análisis de etiquetas usados para organizar, filtrar, decorar y manipular el formato basado en datos extraidos de uno o varios modelos (o como es a menudo, lo que es pasado del modelo a la vista por el controlador).

En una nota al lado, este blog no va a utilizar Smarty. Smarty ha respetado la historia en PHP, pero tiene garves deficiencias una vez que usted comience a pensar en la vista como un rompecabezas de docenas de piezas reutilizables arrastradas junto a un único diseño global. En efecto, este método de administración de la Vista está estrechamente relacionada a la Programación Orientada a Objetos como un concepto en el que se usa a PHP como lenguaje de plantillas, se vuelve casi inevitable. Eso no sin un costo (¿Todos los diseñadores saben PHP?) pero es un costo manejable.


El controlador

Los controladores son engañosamente simples en comparación con los otros. La función principal del controlador es controlar y delegar. En una típica petición PHP a una arquitectura MVC, el controlador toma lo que se ingresó el usuario, supervisa el filtrado de esa información, validación y procesamiento de la entrada, administra el modelo, y finalmente delega la salida para que sea generada por la vista (Opcionalemente lo pasa a uno o mas modelos requeridos para procesar la plantilla actual). El controlador también tiene un única diferencia respecto a otras formas de arquitecturas en PHP, ya que solo requiere de un único punto de entrada en la aplicación - cas inevitablemente index.php.


El Controlador vs El Modelo

Una vista rápida de MVC no estaría completa sin una breve meción de por lo menos una diferencia muy común en aplicaciones MVC. Tomo prestado un término, Esta es la idea de un Modelo Gordo y un controlador Flaco.

Un modelo Gordo, es un modelo que tiene la mayor cantidad de lógica de negocio y manipulación de datos como puedan caber en ella. El resultado es una gran masa de lógica reutilizable y accesible desde cualquier controlador. Esto, en teoría, resulta en un controlador Flaco - cuando toda la lógica se incluye dentro de un modelo adecuado detrás de algunos APIs, el Controlador de tamaño promedio debería ser reducido, Menos código controlador, menos código ordinario oculto en lo que un controlador realiza.

Lo contrario es un modelo delgado y un Controlador Gordo - La lógica de negocio está dentro del controlador que obviamente incrementa su tamaño, y en segundo lugar significa que el código no es reutilizable (a menso que decida reutilizar el controlador desde otro controlador - que rara vez es una buena idea eficientemente sabia).

Conjuntamente, estos son los tres segmentos de una aplicación que implementa un arquitectura Modelo-Vista-Controlador. Es una solución ampliamente reconocida para aplicaciones wen y es evidente en la mayoría de la actual generación de Frameworks para muchos lenguajes de programación.

En el Zend Framewok, estass tres separaciones son representadas por los componentes Zend_Db, Zend_View y Zend_Controller. Estará escuchando mucho sobre estos tres y las clases que los componen en los capítulos que vienen. En conjunto, estos constituyen la columna vertebral de la arquitectura MVC del Zend Framework y se basa mucho en las mejores prácticas.

El Modelo-Vista-Controlador fue utilizado originalmente para promover la "separación de las intereses" en las aplicaciones de escritorio con interfaz gráfica. Al separar cada interés dentro de una capa independiente de la aplicación. que dio lugar a una disminución del acoplamiento que a su vez hizo mas fácil el diseño, escritura, pruebas y mantenimiento de las aplicaciones. Aunque las aplicaciones con Interfaz gráfica de usuario (GUI) se han apartado del MVC en los últimos años, ha demostradado ser altamente efectivo cuando se implementa en las aplicaciones Web.

En el Framewok, este añade un montón de estructuras previsibles desde cada segmento del MVC para que cualquier petición soportada este aparte dentro de su propio grupo de archivos. El controlador está representado por las subclases del Zend_Controller_Front y Zend_Controller_Action, El modelo por subclases de Zend_Db_Table y la vista por archivos de plantillas .phtml y View Helpers. El Zend Framework gestiona la organización de cada uno de ellos en el panorama general, dejandote libre para enfocarse solo en esas agrupaciones sin preocuparse de todo el código que resulta al combinarsen.

En cierto sentido es como construir una casa donde los cimientos, las paredes y el cableado interior y fontanería ya están en su lugar, y todo lo que queda por realizar es la decoración interior y un techo. Puede tomar algún tiempo para aprender a decorar y techar las secciones que ya están listas, pero una vez que has aprendido como hacerlo, después las casas estarán terminadas mucho mas rápido.


En Conclusión

Como he dicho, esto es muy brevemente una comprensión del MVC. No se trata de una exhaustiva, así que sientase libre para ejecutar unas cuantas búsquedas en Google y leer acerca del tema. Para los desarrolladores de aplicaciones Web, la lectura acerca del MVC nunca es un desperdicio. Hay un enorme cuerpo de pensamientos existentes que abarcan temas que van desde la realización de pruebas para MVC hasta que estilos de MVC funcionan mejor para diferentes situaciones.

Siguiente: Investigaremos un ejemplo de "Hola mundo" que no es el ejemplo mas simple posible, ya que ilustra algunas normas de limpieza para mantener este sencillo ejemplo lo mas ordenado y maleable posible.

Si. tendrá código PHP real :-)


------------------------------------------ FIN