Antes y ahora
Rememorando un poco, los servlets (y similares, como perl y cgi) eran programas que generaban completamente el HTML que se requiere para una página. El generar HTML con programas que también podían acceder a recursos como bases de datos, ayudó a tender puentes entre esa información y los usuarios web, y abrió la puerta a un mundo de aplicaciones interesantes.
Aunque la generación de HTML es algo relativamente sencillo, con el tiempo los desarrolladores encontraron un modo más productivo de hacerlo. Si los servlets y similares eran código con HTML incrustado, ASP, PHP y JSP eran lo inverso, HTML con código incrustado. Al voltear el punto de vista se simplificaba el proceso de desarrollo.
Conforme se enfrentan a problemas más extensos o complejos, los desarrolladores van desarrollando también herramientas y organización que les permita ser mas productivos. Por ejemplo, para trabajar en equipo vieron que podía ser conveniente aplicar en el desarrollo web un esquema de trabajo estilo MVC (Modelo-Vista-Controlador), que daba buenos resultados en el contexto de aplicaciones de escritorio.
Quizás la mayoría de los esquemas de trabajo, o frameworks, actuales es del estilo MVC. Como Struts para Java y CakePHP para PHP.
En el MVC, la Vista es el HTML con código incrustado, pero lo menos que se pueda, casi siempre limitándose a variables cuyo valor es establecido desde el Controlador, que accede a tipos de datos más complejos representados por el Modelo.
Es un esquema que funciona bien. Los desarrolladores pueden ubicar con relativa facilidad donde debe ir cada cosa. Sin embargo, al menos por mi parte, expresar cada solución en los términos de MVC está un poco lejos del HTML básico y puede convertirse en un problema adicional.
Drupal es un CMS construido alrededor de un framework que no es MVC pero que es muy interesante, por el modo en que organiza la participación de módulos que se pueden agregar con relativa facilidad. Permite ser muy productivo, pero al menos en mi opinión, tiene un bosque conceptual extenso que toma tiempo reconocer.
Reinventando la rueda
No puedo decir que sea un experto en frameworks. Creo que sólo soy un aficionado, con algunas impresiones y motivaciones respecto a ellos.
En cada framework, veo que la vista sigue siendo HTML con código incrustado. En el caso de javascript, se vió que esto puede hacer difícil de mantener y lo han venido solucionando con Unobstrusive Javascript. Es decir, la buena práctica de mantener el código aparte tanto como sea posible y hacer que participara desde afuera. Sin embargo, en los frameworks que he visto, no he notado ninguna iniciativa similar.
También veo que, cuando un framework nuevo aparece (o incluso una versión nueva de un framework conocido), es de esperarse que haya que reaprender muchas cosas. Volver a aprender a presentar texto, formularios, la programación de acciones y la organización del flujo. Cosas que ya sabíamos, pero que hay que hacer de otro modo. No se que opinen, pero ¿no sienten que esa práctica no es muy eficiente que digamos?.
Algunas veces, por curiosidad, he ensayado hacer algo que funcione como un framework. Es una experiencia interesante y muy motivadora. Ya había podido emular un esquema MVC simple y, cuando conocí un poco de Drupal, me interesó saber si sería posible hacer algo similar, también mas simple.
Empeñado en eso, un día me encontré a QueryPath. QueryPath es algo asi como un puerto PHP de jQuery. Y jQuery es un framework para javascript.
Javascript permite manipular los elementos de una página web. Durante mucho tiempo, hacer cosas en javascript significaba dominar muchos aspectos íntimos de un navegador. Y estaba la dificultad adicional de que había que tratar a cada tipo de navegador de un modo especial.
Pero un framework llamado Prototype uniformizó la manera de tratar con varios tipos diferentes de navegador y javascript empezó a volverse divertido otra vez.
jQuery fue un poco más allá, con la idea brillante de usar los selectores CSS, que se venían manejando para aplicar estilos, para seleccionar con ellos también los elementos sobre los que se quiere actuar.
Otra idea de jQuery es que una función devuelva el mismo elemento sobre el que actúa, de modo que las funciones se pueden encadenar, una tras otra, haciendo mucho más clara la expresión de acciones que antes resultaban complejas de seguir.
QueryPath trata de llevar esas virtudes al mundo PHP.
uphp
Noté que, con QueryPath, podía actuar sobre una página sin incrustarle ningún código. Bonito. Luego, usando el mod_rewrite de Apache, disponible en casi todos los hosting PHP, se pudo hacer que las llamadas a una página fueran atendidas por un php central (una técnica usada por varios framework), que delegara el tratamiento de la acción a los módulos dispuestos para ello (como se hace en Drupal).
Asi, fue apareciendo uphp. El nombre podría ser una abreviación de Unobstrusive PHP, o podría buscarse algo un poco más asertivo. Quién sabe, si resulta ser una buena idea, quizás el prefijo "u" se pueda poner también delante del nombre de otro lenguaje.
Creo que una de las virtudes de atender una página estática unobstrusivamente, desde afuera, es que facilita reutilizar sites ya existentes, navegaciones ya trazadas y todas las técnicas web que ya conocemos.
Me parece que una versión básica estuvo funcional el 1 de abril. Actualmente, uphp está en un estado alfa, pero lo he venido aplicando en el desarrollo de su propio site, desarrollando el framework según las cosas que voy requiriendo.
Esta semana me he aplicado en publicar el proyecto. Es open source bajo la licencia GNU-GPL.
Enlaces
- SourceForce: http://sourceforge.net/projects/uphp/
- Website: http://akobashikawa.byethost6.com/uphp/
- Blog: http://uphp.blogspot.com/
