Tag Archives: desarrollo web

El futuro de la web: HTML 5

22 abril 2010

Con este título he encontrado una presentación de Derek Bender, gracias a un artículo en la web del IES Gran Capitán de Córdoba (España), en el que se presentan datos significativos de cómo será la programación web a partir del año que viene, que es cuando ya todos los navegadores más importantes, tendrán soporte para HMTL 5.

No obstante, los equipos antiguos que aún manejan navegadores antiguos, no podrán visualizar estas mejoras, pero al menos, ya se habrá iniciado una mejor forma de realizar páginas web.

En principio, Derek, nos introduce en la historia de esta nueva liberación. Los grupos de trabajo principales: Apple, Mozilla y Opera (y muchos otros menos conocidos); se reunen para trabajar en una nueva liberación de este lenguaje de etiquetas basado en el uso cotidiano que se le da en estos momentos.

Cambios o Puntos fuertes

  • Se agregan etiquetas para marcar correctamente o de forma más concreta y correcta los elementos que se visualizan en la web: header, nav, section, article, aside, footer, figure…; con lo que, en lugar de usar la etiqueta div en todos los casos, se puede usar cualquiera de las anteriores para indicar que son cuadros de navegación (nav), cabeceras (head), etc.
  • Añaden etiquetas con características nuevas: hgroup, details, summary, mark, output, progress, menu, video, audio…; con lo que se puede incluir de forma más fácil un reproductor de vídeos o audio, modificando su visualización fácilmente a través de CSS, así como barras de progreso, menús, etc.
  • Se dispone de lienzo para poder dibujar: canvas. Este se puede usar para hacer cosas como una visualización personalizada con ampliaciones y cambios en línea (por parte del navegador) como: una lupa o ampliador, o juegos.
  • Se incluyen nuevas APIs: drag’n drop, edición de documentos, caché offline, almacenamiento simple en cliente, almacenamiento estructurado en cliente, mensajería entre documentos…
  • Formularios potenciados, con la agregación de los tipos de entradas: color, number, time, month, date, datetime, datetime-local, url, range, email, search, tel y week. Con esto se permite hacer formularios mucho más simples que den posibilidad de entrada de datos para un selector de colores, fechas y horas, URLs, rango de números, emails, etc. Además de agregar atributos, que los completan: required, autocomplete, autofocus, pattern (para formateado) y más…
  • Se eliminan elementos como: center, font, frameset y strike.

Soporte

Los navegadores que lo soportan, de momento, son Firefox, Opera y Chrome. En 2011, Microsoft, planea sacar IE 9, el cual tendrá también soporte de HTML 5.

Beneficios y Desventajas

Derek señala los siguientes beneficios de HTML 5:

  • Tiene una sintaxis más clara.
  • Elementos semánticos más concretos.
  • Nuevos elementos de formulario que facilitan la programación de los mismos.

Por mi parte agregaría:

  • Hace que se dependa menos de Flas, Silverlight y ciertas librerías de JavaScript.
  • Hace que el navegador dibuje y ejecute de forma más rápida la web.

Las desventajas, que las hay, son:

  • La especificación de HTML 5 no ha finalizado, aún pueden sucederse cambios.
  • No todo funciona en todos los navegadores.

Conclusiones

Como dice la presentación: Evolution, not Revolution; por lo que, como mejora que constituye HTML 5, habrá que tenerla presente, ya que dentro de unos años, la mayoría de los navegadores soportarán estas características y, emplearlas, constituirá una ventaja con respecto al rendimiento, tanto por parte del navegador, como por parte del desarrollador.

La presentación:

The Future of the Web: HTML5
Also tagged – 1 Comment

Comet ha muerto, ¡larga vida a websockets!

29 diciembre 2009

Leyendo el artículo de Joe Armstrong, sobre este mismo título, comenta que con la aparición de websockets (una nueva característica que ha aparecido en HTML5), el sistema comet y otros derivados, están abocados a la extinción.

Desde siempre, el sistema HTTP, llamado también web, ha sido un sistema cliente-servidor, donde el cliente siempre ha sido el navegador web, o cualquier herramienta que pudiese hacer una petición HTTP hacia un servidor, y el servidor, un ente pasivo, se encargaba de procesar la petición y retornar una respuesta. Nada más.

Una de las implementaciones más usadas por este sistema se produce gracias a la característica de HTTP 1.1 de mantener viva la conexión (keep alive) permitiendo al navegador realizar más peticiones y al servidor encauzar una respuesta progresiva, como una lluvia de estrellas (cometas) es el streaming, ya que el sistema puede enviar datos de vídeo progresivamente.

El problema viene dado, también, por la propia especificación de HTTP 1.1, donde se indica que sólo puede haber dos conexiones simultáneas con entre navegador y servidor, con lo que, el uso en una página web con hoja de estilos y bastantes imágenes puede no ser muy aconsejable.

¿Qué aporta de nuevo o de mejorado websockets? a través de HTML y JavaScript de forma simple, se establece una conexión con el servidor dada una URL y un sub-protocolo en el que deben de hablar. Una vez conectado, los elementos html pueden tener eventos del tipo: onopen, onmessage, onclose; indicando los tres eventos que pueden darse en la conexión y el diálogo abierto con el servidor.

Hay que recordar que la interacción vendrá dada por el servidor, esto es que, un programa ejecutándose en el servidor (que no tiene porqué ser de tipo web) puede enviar un evento al puerto especificado por el cliente y el mensaje ser recogido por el navegador y dárselo al elemento al que haga referencia el propio mensaje.

De momento, en Google Chrome se encuentra operativo y se puede probar. En el artículo de Joe Armstrong se puede descargar un código en Erlang para el servidor y un código HTML para el navegador.

Realizaré pruebas y ya comentaré la impresión que me cause el sistema.

Also tagged – No Comments

Lenguajes Funcionales para el Desarrollo Web

13 agosto 2009

La web concurrente, a prueba de fallos y distribuida ya va siendo más fácil de desarrollar gracias a dos iniciativas paralelas. Una de ellas es Erlyweb, el entorno desarrollado por Yariv Sadan que permite realizar de forma fácil sitios web en lenguaje Erlang. La otra es Lift, un framework de desarrollo web para otro lenguaje funcional: Scala.

¿Lenguaje funcional para la web?

Muchos se harán esta misma pregunta, si de siempre, los lenguajes imperativos han sido empleados para el desarrollo de aplicaciones web (Java, PHP, Ruby, Perl, C#, …), ¿por qué emplear un lenguaje funcional como Scala o Erlang?

Las ventajas son las siguientes:

  • El lenguaje funcional obliga a pensar lo que se programa, realmente, en este tipo de lenguajes también es posible cometer errores y hacer barbaridades, pero en menor medida. Por regla general, lo que se programa en un lenguaje funcional, suele ser meditado, pensado y puede ser probado de mejor forma.
  • Obliga a organizar el código, ya que todo gira en torno a crear funciones que se llamen unas a otras y a sí mismas, así como tener el código separado en módulos o bloques funcionales. Por ejemplo, en Erlang, para emplear OTP (gen_server, gen_event, gen_fsm…) se debe de crear un módulo para cada uno de ellos, con lo que todo queda bien organizado.
  • El código resultante es más corto y más legible, ya que el código funcional no reutiliza variables, se basa en listas y tiene menos estructuras de control que los lenguajes imperativos, sí, resulta más fácil de comprender el lenguaje en sí y el código, una vez se va leyendo.
  • Tienen ventajas cuando se habla de concurrencia, tiempo real y tolerancia a fallos. Obviamente, si no se permite la reasignación, no se permite cambiar el valor de un dato ya asignado y, por tanto, no hay cabida para la memoria compartida, con lo que la concurrencia se simplifica de forma sorprendente. Por otro lado, estos lenguajes han sido pensados y desarrollados para distribuirse en varios nodos y/o equipos, pudiendo migrar sus procesos entre nodos y sustituir al nodo principal en caso de no estar operativo.

En lo que respecta al lenguaje en sí, se ve claro y, hasta muchos pensarán: ¡mierda!, he perdido el tiempo aprendiendo y usando PHP (o Perl, o Ruby, o Java…); pero no hay que ser tan radical, estos lenguajes son muy útiles y ofrecen muchas ventajas a los lenguajes tradicionales web y, gracias a los frameworks desarrollados, las mejoras son increíbles.

Si tan bueno es… ¿por qué no se usa?

Seamos sinceros, la razón de uso de un sistema u otro se basa, íntegramente, en la popularidad, la costumbre y los malos usos. Cuando en tu entorno hasta 3 personas dicen que PHP es bueno para la web, ya sabes que es lo que hay que aprender si quieres hacer web, pero eso no debería de ser lo único a calibrar, y sobre todo si el conocimiento que se adquiera de PHP se usará para el desarrollo profesional de aplicaciones.

Erlang lleva muchos años usándose en el terreno de las telecomunicaciones y Yariv, el creador del framework Erlyweb, integra servicios desarrollados en Erlang para Facebook, con lo que, los grandes de Internet, ya se han dado cuenta de que hay que dar un paso hacia adelante. Por otro lado, Scala es usado en otros sitios como Twitter.

Ahora de verdad, ¿por qué usarlos?

El desarrollo de entornos web conlleva el uso de varias tecnologías que se usen de forma coordinada y limpia. Desarrollar un software en cualquier lenguaje mezclado con SQL y código en HTML con CSS incrustado y código JavaScript repartido por todos lados hace que el código sea difuso. Difícil de entender.

Sin embargo, con C# y Java se comenzaron a emplear soluciones que han ido trascendiendo a lenguajes de scriptting como Ruby, Python o PHP, en los que ya no se dejan ver consultas SQL, sino el uso de objetos y funciones, el código de presentación queda almacenado por separado con etiquetas especiales, helpers y otros añadidos, los códigos HTML validados, los CSS en sus respectivos ficheros aparte y agregados desde la sección pertinente e incluso el uso del JavaScript no intrusivo.

Llegados a este punto, nos encontramos con que, desarrollar web es, tan solo, desarrollar. Realizar el programa en un solo lenguaje y de forma fácil. Pero aún así, volvemos a encontrar lo que ya había tiempo atrás, nuestro lenguaje imperativo puede contener fallos lógicos y, si es un lenguaje de scriptting muy permisivo, algunos de esos fallos son difíciles de perseguir.

El uso de un framework como lift o erlyweb facilita el seguimiento de fallos, desarrollar en erlang y scala facilita el desarrollo propio de la aplicación y agrega factores determinantes de crecimiento de la misma, así como estabilidad, ¿qué más se puede pedir?

Also tagged , – No Comments

Escalado de Ruby on Rails

25 mayo 2009

Después de liberar el primer proyecto escrito en Ruby on Rails, cuando lo pasamos a producción, nos dimos cuenta de que el sistema funcionaba realmente lento. En algunos casos, incluso, no respondía, con lo que buscamos información por internet y vimos:

Mongrel y Thin no son multi-hilo

Fue algo que nos sorprendió mucho, una aplicación servidora secuencial, que atiende las peticiones una a una y, en caso de que una petición se tarde un par de segundos (que las teníamos :-S ), el sistema se queda trabado durante todo ese tiempo.

Las soluciones posibles eran dos:

  • Phusion Passenger, también conocido como mod_rails, es un módulo para Apache que mantiene tantos hilos como peticiones se vayan gestionando, siempre con unos límites máximos y mínimos, tal y como apache suele hacerlo.
  • Ngnix + Thin, esta solución fue un poco más artesana, por decirlo de alguna forma, ya que consistía en configurar este servidor web como proxy inverso, para hacer el balanceo de peticiones entre todos los hilos de thin que se quieran cargar en el sistema. Descartamos en este punto a mongrel por comentarios que había leído en otros blogs.

Bien, por correr lo más posible, lanzamos tantos hilos como nos fue posible en la máquina que dedicamos al proyecto y, nos complació ver que podía aguantar hasta 40 hilos, sin que sus CPUs lo notasen apenas. Con lo que conseguimos un pool de 40 puertos dedicados a atender peticiones HTTP.

En otra máquina se configuró un proxy inverso. En el escenario de pruebas usamos nginx, aunque el tenerlo en la misma máquina y hacer pruebas masivas, nos dio como resultado que una cantidad importante de peticiones se perdían o transformaban en respuestas de tipo 500 por parte de nginx. Optamos entonces por un balanceador que tiene la compañía vía hardware, muy rápido y, a día de hoy el sistema web tira tan rápido y casi mejor que el que tenemos montado en PHP :-)

En el próximo artículo comentaré las configuraciones, arquitecturas y demás seguidas, sobre todo a nivel de nginx y thin, que es lo que realmente interesa.

Also tagged , , , – Comentarios desactivados

JavaScript y CSS no intruso en HTML

8 febrero 2009

Cuando se pensaba en MVC, la capacidad para dividir las tareas obvias de tratamiento de datos, en lógica de negocio (el modelo), control de flujo de ejecución (el controlador) y la presentación de datos (la vista), aún quedaban en el aire muchos problemas en lo que respecta a las interaces, propiamente dichas, entre estas tres capas.

Centrándonos en la vista, existen miles de soluciones, para alejar al diseñador del código y al programador del diseño, pero aún así, cuando se habla de AJAX y desarrollos específicos… el programador tiene que tocar diseño y el diseñador preocuparse de lo que hará el código de servidor.

Este dolor de cabeza puede paliarse mediante el uso de códigos no intrusivos, lo que facilita la especificación de una interfaz basada en identificadores para el tratamiento del HTML.

El código no intrusivo de servidor lo trataré en otro artículo para que no resulte este muy extenso.

CSS no intrusivo

En principio, desde el punto de vista del navegador, todo es HTML. Pero, al igual que en los procesadores de texto, para facilitar la estructura de estos ficheros y no plagarlos de contenido referente a tipos de letra, colores, fondos… se crearon las hojas de estilos.

Las hojas de estilos en cascada (CSS) ayudan, junto con la especificación de identidades y clases, a dar estilos (colores, fuentes y forma de presentación en general) a las etiquetas escritas en HTML.

El CSS se pude incrustar en las etiquetas HTML mediante el uso de las etiquetas style, o incluso a través de los atributos style dentro de cada una de las etiquetas típicas de HMTL.

La mejor forma de hacer que no sea intrusivo, es colocar esos estilos en un fichero separado, y agregarlo mediante el uso de la etiqueta link en la sección head.

JavaScript no intrusivo

El código JavaScript es algo que se ha ido haciendo cada vez más con el HTML. En principio, se usaba la etiqueta script dentro de la sección head para agruptar todas las funciones de javascript, a las que se iban llamando desde etiquetas como onclick, onmouseover, onchange…, es decir, las etiquetas de eventos de HTML, que se destinan para JavaScript.

Después su uso se fue masificando y mezclando cada vez más con el HTML, haciendo que la etiqueta script, en muchas páginas, se encuentre repetida y segregada a lo largo de todo el texto HTML y, además de eso, en atributos como href, donde se indica explíticitamente que se ejecutará un código javascript.

Esto hizo que el código javascript se convirtiese en parte simbiótica de HTML y, en muchos desarrollos, que no se pudiese separar fácilmente.

Con ciertas técnicas, como las usadas en CSS, la separación de JavaScript se puede llevar a cabo sin problemas, pero requiere de ciertas pautas y costumbres a la hora de realizar el HTML:

  • Asignar ID a las etiquetas con las que se vaya a trabajar dinámicamente.
  • Asignar una clase a todo tipo de etiquetas que se usen para un fin similar.
  • Intentar no realizar anidamientos muy profundos.
  • En caso de tenerlos, intentar diferenciar los niveles de profundidad con IDs claros.
  • No abusar de tablas.
  • Tener especial cuidado con las etiquetas div, sobre todo por su uso con varios navegadores.

Con esto, solo tener claro que, el fichero de tipo javascript que se asocie al HTML, debe tener un código lanzador, que se encargue de asociar las funciones javascript oportunas a los eventos y las modificaciones pertinentes.

Es importante también recordar que, para mejorar la depuración, es mejor generar cuanto menos código por javascript, mejor. Es decir, que si hay que modificar las propiedades de una tabla por dar la posibilidad de varios tipos de ordenación, hacer las funciones específicas para ese cambio en JavaScript, pero no caer en la tentación de pasar los datos a array de javascript para hacerlo todo desde ahí.

Conclusiones

Lo que se trata, en base, es llegar a lo que W3C considera que debería ser la web semántica, pero con el uso de HTML. Intentar organizar los datos con las etiquetas existentes, sin usar estilos de presentación, solo los datos, y agregar a esas etiquetas el estilo de presentación deseado, mediante CSS externo y el dinamismo de cliente que se requiera, mediante JS externo.

Las ventajas que agrega, es que el cambio de una presentación a otra, se puede hacer con tan solo variar el CSS, y agregar nuevas funcionalidades, es solo modificar el JS.

Also tagged , , – Comentarios desactivados

Desarrollo Web

20 enero 2009

Hace tiempo, comenté acerca del desarrollo web en plataformas como Java, PHP, Erlang, Python… en ese momento, veía la maraña en la que está tejida la red de redes, el abanico de posibilidades a la hora de desarrollar una aplicación web y comenzaban a sonar términos como CRUD, SOA, MVC, ActiveRecord, Scaffolding…

Es una verdad que cada entorno, en cada lenguaje, ha ido implementando una serie de características que facilitasen y acelerasen la creación de entornos web, de toda índole, en poco tiempo y, una vez aislada la idea base, dado un nombre e incluso un acrónimo de tres letras (como el buen Jargon file manda :-) ), se convierte en un concepto de estudio e implementación en el resto de lenguajes.

A este respecto, PHP ha sufrido una desaceleración en innovación. La cantidad de estas características que pululan entre el resto de lenguajes, que la mayoría los orientan a objetos, quedan en imposibilidad de implementación, o en una implementación algo sucia, cuando se hacen en PHP, debido a su, aún, pobre implementación de orientación a objetos.

No obstante, en PHP se pueden identificar buenos entornos de trabajo que hacen, o en los que se pueden emplear y usar todos estos conceptos, como son Code Igniter o Simfony.

Algunos conceptos a tener en cuenta y que no se nos olviden, como buenas prácticas para el desarrollo de sitios web son:

  • CRUD: create, retrieve, update y delete; es usado como sistema base para gestión de la información, con las cuatro tareas básicas que se suelen hacer sobre cada entidad de base de datos típica.
  • SOA: arquitectura orientada al servicio; es una forma de diseñar nuestras aplicaciones de forma que se tenga presente siempre el nivel de aplicación, el servicio que se va a prestar.
  • MVC: modelo-vista-controlador; es una separación lógica de las aplicaciones en lógica de negocio (modelo), presentación o vista, y controlador del flujo de ejecución.
  • ActiveRecord: es una forma de aislar la sintaxis SQL del programa base. Intenta emular al sistema que se usaría con un sistema de base de datos orientado a objetos, pero a través del mapeado de las tablas con los atributos de las clases.
  • Scaffolding: realiza, automáticamente, el paso de tablas de base de datos a CRUD y/o ActiveRecord. Es un sistema que intenta automatizar, lo máximo posible, la generación de entornos simples de metodología CRUD.
  • Rutas: es la forma en que las aplicaciones web pueden hacer uso de la llamada a un método específico con unos parámetros específicos y de una forma elegante, a través de un sistema tipo ruta en la URL.
  • AJAX: el uso de AJAX para agregar dinamismo a la web es un factor del que no se debe de abusar, pero que se debe tener en cuenta, ya que hace que la carga de páginas se reduzca de forma drástica.

En poco tiempo, supongo y espero, haré esta lista algo más grande, porque sé que se me olvidan más conceptos, pero de momento, así se queda :-P

Comentarios desactivados

Programación Rápida de Webs

3 noviembre 2008

Cada lenguaje que es potencialmente útil para el desarrollo web, termina teniendo un framework para el desarrollo de aplicaciones web de forma rápida. A continuación pongo un listado de los lenguajes con sus respectivos entornos (los más usados y/o conocidos):

  • Ruby: este lenguaje dio el salto al desarrollo web con su framework denominado on Rails. Es un sistema que ayuda al desarrollador para realizar un sitio web dinámico que requiera de acceso a datos y características típicas de los CMS, foros, webmails, etc.
  • Java: el desarrollo de aplicaciones empresariales siempre ha estado marcado por Java. En el desarrollo web, Java usa tanto servlets como JSP. Un entorno muy conocido que se comenzó a usar en el patrón MVC con Java fue Struts. Se considera de los primeros. Luego hay otros que se consideran más completos, como por ejemplo Spring.
  • PHP: en PHP realmente no haría falta ningún entorno en sí, pero ciertamente, para marcar el camino de un desarrollo grande para una empresa, debería de existir un método que permita a varios programadores no realizar código difícil de mantener. En este sentido, hay entornos como CakePHP o como Symfony, que facilitan pensar todos los aspectos relativos al desarrollo de una aplicación web grande y pone en manifiesto pocos patrones de desarrollo a seguir. En BosqueViejo tenemos nuestro propio framework para desarrollo de CRM: Oak Framework.
  • Erlang: dispone también de ErlyWeb que al igual que los frameworks de los demás lenguajes, permite el desarrollo rápido de elementos basados en base de datos y similares.
  • Python: es un lenguaje que se ha basado, para la web, casi siempre en la existencia de Zope para el desarrollo de aplicaciones (o productos) de forma fácil y rápida. No obstante, hay mucha gente que comienza a usar otros frameworks como Django.
  • Groovy: este lenguaje, concebido como lenguaje embebido para Java, se ha comenzado a usar como simplificación del mismo y uso en sistemas de scripting y con el framework Grails en la web.
  • Perl: este lenguaje script, de los más rápidos en ejecución y con una sintaxis que, hace tiempo, se ganó el apodo de write-only, tiene también su framework para el desarrollo web, cuyo nombre es Catalyst, y se encuentra disponible en su propio CPAN.

Cada uno de estos lenguajes tiene su potencial y es más indicado para un tipo de desarrollo que los otros. Hay que tener en cuenta que, los lenguajes más estructurados (Python y Java, por ejemplo) tienen la propiedad de poder estructurar de forma correcta el código, con lo que son más indicados para proyectos grandes y muy configurables.

En cambio, para proyectos pequeños, el uso de otros lenguajes rápidos como Groovy, PHP, Perl o Ruby, está mejor indicado puesto que, aunque son lenguajes perfectamente válidos para desarrollos grandes, su potencia radica en la posibilidad de escribir código rápido y, muchas veces, de cualquier forma, y terminan convirtiéndose en códigos difíciles de mantener.

Sin embargo, hay muchos proyectos desarrollados en estos lenguajes que han demostrado que, con un poco de organización y una política algo estricta a la hora de escribir código, permiten al equipo de desarrollo mantener y hacer que un sistema web se haga grande a lo largo del tiempo, como han sido: WordPress, Drupal, eGroupware, LiveJournal, Radiant, etc.

Otros lenguajes de alta escalabilidad, como Erlang, que permite el desarrollo de aplicaciones en varios nodos (equipos) de forma fácil, sin necesidad de emplear aplicaciones y servidores extra, que al fin y al cabo, resultan siendo un SPOF más en nuestro sistema.

Como conclusión, podemos sacar que, para la web, cualquier lenguaje es válido, y sus respectivas comunidades nos lo demuestran día a día. Si el proyecto que hay que realizar es pequeño, introducirse en Java o Python (a menos que sea Plone y/o Zope) es algo costoso, mientras que si se hace en otro lenguaje de scripting, suele ser más rápido. Pero cabe recordar que, si el proyecto es grande, lo que hay que hacer, es un planteamiento y una línea general, una política de actuación y llevar siempre el código claro y limpio, sobre todo si lo queremos mantener y reutilizar en el futuro.

1 Comment

Cloud Software

16 septiembre 2008

Con este título, comienza a surgir una tendencia a usar más servicios en web. Esto viene acompañado de la liberación hace unos días de Google Chrome, el cual, aseguraban muchos expertos que no hace la competencia a Internet Explorer, Safari o Firefox, sino que se la hace a Windows.

Esto viene determinado porque el navegador se ha convertido en todo un sistema operativo en el que se ejecutan aplciaciones que se cargan de forma remota. Lo que ya habían visualizado hace años Sun con el uso de sus paquetes en forma de nombre de dominio y otros… pero de una forma mucho más transparente.

En el navegador web, solo hay que poner una dirección web (URL) y con ello se puede acceder a un software con el que se interactúa para: leer el correo (Gmail, Yahoo!, Hotmail…), tener la agenda de contactos (en los mismos webmails), escribir diarios (blogs como Blogger), organizar las fotos e imágenes (fotoblogs o galerías tipo Flickr)… e incluso tener acceso a bancos, tiendas, el Estado…

Microsoft ultima su Office Online, junto con aplicaciones de tipo Office que ya tenía en uso Google mediante Google Docs, y con ello, con todo en Internet, ¿qué más da ejecutar un Windows, GNU/Linux, MacOS X…?

1 Comment

MVC en PHP, ¿es correcto?

7 diciembre 2006

Después de haber realizado una investigación sobre el tema, he hallado una serie de enlaces, donde se destacan cosas como que el único MVC oficialmente creado es phpMVC, o cosas como que MVC no es para PHP.

En principio, buscando alternativas, además de phpMVC tan solo encontré Kenda, el cual se encuentra en un estado muy inicial y con muy poco apoyo.

Hay personas como Jim Lim, creador de ADODB, que consideran mala idea el portar MVC a PHP, sobre todo porque parece ser que nadie sabe aún como debería de hacerse. En su blog, Jim, señala seis puntos para los que MVC suele fallar:

  1. Control centralizado sobre los derechos y accesos a la página
  2. Habilidad para remapear URLs debido a cambios en la estructura web
  3. Manejar inteligentemente errores 404
  4. Habilidad para, dinámicamente, añadir cabeceras y pies a páginas para mostrar alertas tales como “sistema se apagará a las 5:00″
  5. Separar el contenido de la presentación de una forma razonable, ej. con plantillas.
  6. Administración de datos “manchados” (ej. GET, POST, COOKIES)

Con estas premisas, nos queda investigar un poco en, ¿qué es exactamente MVC? y así podremos responder la pregunta que motiva este artículo.

M: Modelo, es la lógica de negocio, es decir, toda función que nos permite extraer datos, ya sea de una base de datos, con proceso intermedio o sin él.

V: Vista, es la presentación de la aplicación. Se basa en tomar los datos con los que se tiene que formar una presentación y conformar el documento, ya sea HTML, WML, XML o cualquier formato de salida hacia el usuario.

C: Controlador, es la parte que une a la lógica de negocio o modelo con la presentación o vista. Se encarga del transporte de datos entre uno y otro y de hacer de interacción con la entrada del usuario, sistema, periféricos, etc.

En este respecto, sobre el Modelo tenemos ADODB, que nos permite abstraernos de la base de datos para preocuparnos solo de la lógica de negocio propiamente dicha, es decir, los algoritmos que se necesitan para procesar los datos.

En la vista tenemos varias optativas, una de ellas es el uso de Smarty. Esta librería ofrece una conversión de etiquetas al estilo XML dentro de un documento de plantilla HTML, lo cual sirve para que el diseñador realice la página de plantilla sin problemas y, el programador, utilice la misma, u otras, sin variar su código.

En la vista también es usual el uso de XML/XSLT. La salida hacia el navegador se realiza en XML teniendo en cuenta solo la organización de los datos que se deben enviar al cliente y, una hoja de transformación (XSLT) se encarga de transformar ese fichero XML en un fichero HTML, WML.
La parte del controlador es algo más crítica y, a su vez, la más importante. En los proyectos phpMVC y Kenda, lo que se ofrece es, justamente, esta parte en forma de frameworks. No obstante, siempre está la opción de hacerlo uno mismo, puesto que PHP en sí, contiene suficiente funcionalidad en su API como para realizar la gestión de todo lo que realiza el controlador de forma asequible.

Bueno, después de haber tratado más ampliamente el tema, ¿es correcto el uso de MVC en PHP? a lo que podemos responder que sí, si el proyecto es grande y requiere de una clara división de Modelo y Vista (programadores y diseñadores) pero a su vez es simple y, no, si el proyecto es pequeño o con muchos matices complejos de gestión de accesos, permisos y control de fallos desde el servidor.

¿Qué opináis?

Also tagged , – 2 Comments