2011/07/18

Liberando la V, otra forma de usar un framework MVC

En el esquema MVC, se tienen modelos que proveen datos, y controladores que toman los datos y los procesan de algún modo antes de enviar el resultado a la vista.

En web, los framework MVC tratan de seguir este esquema para organizar el trabajo. En teoría, parte del equipo se puede enfocar en los modelos, otro en los controladores y otro en las vistas.

Al margen de si en la práctica realmente se cumple esto, es notable un problema: los modelos, vistas y controladores desarrollados determinan finalmente un API no estándar que termina "enjaulando" el producto final. Si decide actualizar el framework a la siguiente versión, encontrará que puede acarrear para el site un trabajo similar a volverlo a hacer. Aún más difícil es pasar un site de un framework a otro.

Esto genera algunos vicios. Si otro framework implementa cierta característica ventajosa, no lo podemos usar; tenemos que esperar hasta que algo similar sea implementado en el que usamos. Esa característica debe ser expresada otra vez, en los términos de nuestro framework.

En mi opinión, esto ocurre porque la página web ha sido forzada a encajar en el esquema MVC sobrescribiendo sus características estándar por otras propietarias, definidas por su sistema de templates particular.

Sí, aunque el framework sea open source, en este caso se está comportando como un ente propietario. Y eso es lo que provoca esta limitación de libertad.

Para tener más libertad, libere la vista. Puede desarrollar su sitio web de modo que las vistas sean HTML estándar y las partes dinámicas carguen con javascript (AJAX) los datos obtenidos de invocar algún framework.

Por ejemplo. Si uso Drupal como framework, puedo tener un subdirectorio drupal dentro de mi site, e invocar con javascript a algo como drupal/action.json, cuyo resultado reflejo en la página.

No hay problema con las páginas del site mientras no cambie el modo de invocar la accion. Si luego cambio la versión de drupal, no seria necesario cambiar las vistas.

Si, en lugar de usar drupal como nombre del subdirectorio, hubiera usado algo como framework, y colocara dentro acciones que se invocaran del mismo modo, entonces, podría usar cualquier framework, con tal que siguiera el protocolo esperado por las vistas.

Esta forma de trabajar puede permitir funcionar un sitio dinámico que use muchos frameworks diferentes en simultaneo. Uno para el login, otro para los listados, otro para comunicaciones, etc. El que mejor haga lo que queremos. También facilita la actualización de los frameworks a versiones superiores.

Usar javascript para esto me parece un camino relativamente asequible en este momento. Pero si alguien no desea usar javascript para eso, podría usar un framework unobstrusivo (que respete la integridad de las páginas), como uphp, para hacer el trabajo de reemplazo. uphp usa querypath para ubicar un elemento en la página (al estilo jquery, pero con php), y reemplazarlo por algún resultado; todo eso en el lado del servidor.

En este otro modo, no son las vistas las que invocan las acciones, sino los controladores que se disponen en el framework unobstrusivo (o uframework, para abreviar). El uframework podria invocar a otros frameworks para hacer los reemplazos de los resultados en las ubicaciones pertinentes en la vista. Igual, se podría usar varios frameworks a la vez.

La idea principal es que la vista salga de la jaula del framework, se respete su integridad, tal como es, y sea independiente de los motores que se usen para generar el contenido dinámico.

2011/07/08

Generación modular de HTML

Actualmente, cuando desarrolla un sitio usando cierto framework, no lo puede modificar con otro. Si está metido en esto, puede parecer obvio y hasta natural. Pero, si lo vemos en perspectiva, es algo así como una limitación por diseño. Algo que se podría mejorar.

Sites estáticos y dinámicos
Aunque el objetivo final es enviar html al navegador, en el desarrollo de sites dinamicos el paso intermedio es crear un conjunto de archivos que generen el html que se desea.

Cuando se trata de sites estáticos es más simple. Uno coloca los archivos en el directorio web y el servidor web los envía al navegador tal cual. Esos archivos son html, css, javascript, o imágenes que el desarrollador puede modificar con la libertad de elegir entre muchas herramientas para eso.

Cuando se trata de sites dinámicos las cosas se suelen complicar. En general, primero se plasma el diseño en un site estático, que luego es desmantelado para ver el modo de generarlo. Finalmente, se obtiene el site dinámico, que actúa como un generador total del html que se desea.

Ese suele se el enfoque más usado. Practicamente siempre que use C, Java, PHP, Ruby, Python, o lo que sea, lo que construye es siempre un generador total de html.

Frameworks exclusivos
El enfoque de la generación total tiene el problema de tender a soluciones monolíticas, con sus vicios asociados.

Si quiere modificar el site, tiene que modificar el generador, y tiene que entender el framework-que-todo-lo-hace.

Cuando un framework mejora, esa nueva versión no le sirve para el site que hizo con la versión antigua y tendría que reescribir el site bajo los nuevos términos.

Si otro framework implementa una característica que le gustaría, tendrá que esperar hasta que sea implementada, otra vez, en los términos del framework que usted usa.

Un montón de trabajo repetido.

Frameworks inclusivos
Una alternativa podría ser hacer generadores modulares. En lugar de generar el html de toda la página, un generador modular sólo produce el html de cierta región específica.

Para indicar dónde colocar el html dinámico, habrían algunas alternativas:

  • Que la página use javascript, obtenga el resultado y lo coloque.
  • Que la página use un tag especial que se reemplace por el contenido dinámico.
  • Que el servidor ubique los lugares dónde hacer el reemplazo y los haga.

La primera alternativa es relativamente asequible con lo que ya tenemos. Para las otras, habría que hacer un framework que se encargue de hacer los reemplazos adecuados (por ejemplo uphp).

Ya mismo podríamos empezar a desarrollar sites de ese modo. Una ventaja grande de usar generadores modulares, es que no importa en que lenguaje de programación se hacen, ni que framework usan, ni que versión del framework. Simplemente se usan. Podría usar generadores modulares escritos en C, Java, PHP, Python y Ruby... todos juntos!

Más artículos