martes, 24 de junio de 2008

REST

Representational State Transfer

Roy Fielding's explanation of the meaning of Representational State Transfer

"Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use"


Basicamente REpresentational State Transfer que podría ser traducido como Transferencia del Estado de Representación, es un estilo de arquitectura, que pretende aprovechar los factores que han hecho que la WWW sea tan exitosa.

La Web puede verse como una serie de recursos, los cuales contienen información directamente consumible y/o enlaces a otros recursos, cada vez que un recurso es pedido al servidor se está accediendo a un Representación del mismo, y esta representación pone a la aplicación cliente en un estado. Por ejemplo, al pedir la página http://fooserver/products/ (la dirección no existe, es solo de ejemplo) estamos accediendo a un recurso que nos muestra un listado de productos y coloca a la aplicación en el estado A, y si al hacer click sobre el link del producto accedemos a su descripción estaríamos siendo transferidos hacia otro Recurso y por tanto cambiando de estado digamos a un estado B. de allí el nombre de REpresentational State Transfer.

En realidad el concepto no es algo totalmente nuevo, se basa en la idea de cada recurso debe poder ser:

  • Único
  • Accesible
  • Humanamente Legible
  • Independiente del Estado, o agnostico de los Estados Anteriores
  • Bookmarkable
  • Usar sustantivos en los recursos en lugar de verbos. por ejemplo ...products/parts/0012, en lugar de ...products/getPart?Id=0012

Hemos venido usando RESTful Services todo el tiempo, pues es la forma inherente en que funciona la web misma.

Habrá que seguir investignado acerca de REST

sábado, 21 de junio de 2008

Zend Framework + Smarty vs Simple Zend View Script

Smarty

Descripción

Smarty es un Template Engine, o más propiamente un Template Framework. Sus características van más allá del simple reemplazo de variables o reemplazo de tags. Su principal característica es que las plantillas (Templates) solo son leídas e interpretadas una sola vez, como resultado de esta lectura se crea un archivo con código PHP el cual es ejecutado durante los subsiguientes pedidos de las plantillas. Esta característica es conocida como Template Compiling.

Beneficios

  • Es rápido, (ellos ponen en este acápite, EXTREMADAMENTE RÁPIDO).
  • Es eficiente dado que las plantillas se compilan a código PHP, reduciendo el overhead después del primer pedido de la plantilla.
  • Las plantillas se recompilan solo si es que estas han sido modificadas
  • Se puede configurar a gusto, desde los delimitadores, hasta las funciones y modificadores de variables, haciendo que su lenguaje sea realmente extensible.
  • Las estructuras de control (Sections, if, etc) pueden estar anidadas y ser tan complejas como se requiera.
  • Se puede incluir código PHP directamente en la plantilla, pero NO ES RECOMENDADO, dado que va en contra del espíritu de la plantilla.
  • Soporte de Cache integrado. Es decir que se guarda el resultado de la ejecución de una plantilla para un request dado, si otro request con los mismos parámetros es hecho luego se devolverá la página que se tiene en Cache. Puede manipularse que secciones de la plantilla no deben guardarse en Cache.
  • Se puede modificar la función de manejo de Cache (Cache Handler Function) por ejemplo para utilizar una base de datos como proveedor de Cache en lugar del Filesystem.
  • Es extensible a través de su arquitectura de Plugins

Desventajas

  • Programar las Plantillas (Templates) (o Diseñarlos) requiere que la persona encargada (usualmente el diseñador) aprenda un lenguaje de tags y expresiones que pueden serle igual de complejos que aprender la sintaxis del mismo PHP.
  • Sin el uso del Cache de Smarty, el rendimiento decae considerablemente. Y aún cuando se use el Cache, la lectura de un template durante un request es una operación costosa (por el acceso al sistema de archivos) lectura que al parecer siempre se hace, para verificar si el archivo de plantilla ha cambiado y por tanto necesita ser recompilado.
  • Aun cuando se separa claramente la lógica de la Vista de la lógica de Negocio los editores de HTML (como el dreamweaver) no siempre hacen un buen trabajo interpretando los tags del Template System. (aunque hay algunas extensiones para el caso del dreamweaver para que soporte Smarty).

 

View Script (Zend View Default)

Descripción

Zend utiliza por defecto para las vistas los View Scripts, que no son otra cosa más que archivos php (con toda la sintaxis del mismo php) que se ejecutan dentro del scope de la instancia de la vista que lo ha llamado (Zend_View instance) por tanto todas las referencias a $this dentro del archivo de scripts hacen referencia a las variables asignadas a la instancia de la vista. Por ejemplo si en el controller tenemos

$ZendView->Something = ‘here is something’ 

En el View Script se accesa a la variable de esta forma

$this->Something 

Beneficios

  • PHP es por si mismo un Template Engine, los View Script están escritos en PHP, por lo que no sería necesario un Template Engine encima de él.
  • Mayor velocidad en la ejecución de los View Scripts, (Son ya código PHP, por lo que no necesitan ser compilados)
  • No se necesita aprender un nuevo lenguaje, si se sabe PHP se sabe programar View Scripts
  • Se tiene acceso a todo y se puede ejecutar todo tipo de código dentro del View Script pues es un archivo .php común. No se depende solo de las funciones que un Template Engine provee o de los plugins que existan para el mismo.

Desventajas

  • El código php puede no ser tan claro como los tags usados dentro de una plantilla
    • Por ejemplo

SMARTY

<body>	<div>{$variable}</div></body>

VIEW SCRIPT

<body>	<div><? $this->variable ?></div></body>
  • Un diseñador común no suele tener conocimientos de PHP y puede parecerle más fácil aprender el lenguaje de los Templates Engines que un lenguaje como PHP.
  • No tiene estructuras de control ni plugins, por lo que hay que escribir bloques de código php para manejar los loops y la generación automática de html.

 

Conclusión

La elección de Smarty como Template Engine para manejar las vistas dentro del Zend Framework, pasará por la evaluación de ítems como:

  • Experiencia de la gente involucrada en el proyecto
  • Necesidad de tiempo de respuesta de la aplicación (Siempre y cuando el tema del tiempo de respuesta sea algo realmente vital) ver enlance: http://template-bench.iliakantor.ru/. De hecho al ser simplemente archivos PHP los View Script tienen la ventaja. Pues integrar Smarty al Zend Framework involucra un overhead que podría evitarse si se utiliza solamente los View Scripts. Aún cuando este overhead podría ser asumible teniendo en cuenta que Smarty provee un diseño de la Vista “más Limpio”.
  • Experiencia de los diseñadores web involucrados en el proyecto.

En particular me inclinaría por recomendar el uso de Smarty, por ser un Template Framework bastante extendido y bastante fiable y que al parecer no representaría mayores inconvenientes integrarlo con el Zend Framework.

La integración podría realizarse de varias formas. Una de las cuales está incluso documentada en la misma página de Referencia del Zend Framework.

Otras implementaciones incluyen la construcción de una clase Factory que permita intercambiar fácilmente entre plantillas de Smarty y View Scripts de Zend, e integrarla haciendo uso de las clases utilitarias del Zend framework.

Fuentes

Vínculos Web