Test VCO

Unobstrusive web dev

Lea el artículo original en Unobstrusive web dev.

Programando Web

Algo de historia
El objetivo de la programación es resolver problemas con ayuda de la computación.

Al inicio, programar una computadora fue cablear una cierta configuración en los circuitos de una computadora.

Luego, fue mover los interruptores adecuados.

Después, fue escribir las instrucciones para que la computadora misma creara la configuración deseada.

Al comienzo, las instrucciones eran binarias; luego mnemotécnicas que representaban secuencias binarias; después, declarativas que representaban secuencias mnemotécnicas.

Muchos, si no todos, los lenguajes de programación actuales emplean declaraciones que definen bloques lógicos que se colocan en secuencia.

Una cierta secuencia lógica se puede aislar en algo conocido, en general, como procedimiento. Los procedimientos que retornan un valor son llamados funciones. También se puede decir que lo que hay son funciones, y que los procedimientos simples son funciones que retornan un valor nulo.

Un cierto conjunto de procedimientos y variables se puede aislar en algo conocido como clase (de objeto). Una clase (de objeto) funciona como un tipo de variable. Así como una variable que instancia el tipo int es un entero, una variable que instancia cierta clase (de objeto) se llama objeto (de esa clase).

La programación que usa objetos se llama orientada o objetos, o OOP (por sus siglas en inglés). En contraposición, a la que no los usa se le llama procedural.

OOP y Procedural
Una ventaja de la OOP es que brinda una mayor claridad para resolver problemas relativamente complejos. Una compleja solución procedural, con un sistema complejo de reglas, suele tener una solución OOP más simple, que suele ser más simple de entender y mantener.

Para la computadora, ambas soluciones funcionan. OOP es para facilitar las cosas a los humanos, de modo similar a como lo hicieron, en su tiempo, la misma programación procedural, la assembler con sus mnemotecnicas, o la binaria, etc. Cada una surgió para facilitar las cosas a los humanos.

Interpretado
Programar en OOP suele requerir un trámite un poco mayor que la programación procedural. Hay ciertas prácticas burocráticas, que hay que seguir, al margen del problema que se soluciona. Hay esquemas previos para definir clases, con sus métodos (procedimientos o funciones), propiedades (las variables) y bibliotecas auxiliares.

La programación procedural también requiere algo de burocracia para eso, aunque un poco más simple, en general.

Esto es porque los programas, OOP o procedural, escritos en un lenguaje cercano al humano, tienen que ser traducidos a binario, el lenguaje del sistema operativo de la computadora, para que los pueda ejecutar. Y los trámites tienen que ver con esa tarea de traducción, llamada compilación.

Antes que se pueda ejecutar, el programa fuente, que entendemos los humanos, tiene que ser compilado para que lo entienda la computadora.

Una forma de simplificar esto, para los humanos, es con la programación interpretada. Allí, un programa llamado intérprete se encarga de todos esos trámites, permitiendo al programador concentrarse en el problema.

Hay intérpretes para lenguajes OOP y procedurales también.

Ejecutar el código fuente interpretándolo cada vez que se ejecuta suele ser más lento que ejecutar su versión compilada pero facilita las cosas para los humanos. Además, para resolver la cuestión de la velocidad, es posible obtener versiones compiladas de programas desarrollados con la ayuda de intérpretes.

Web
Una página web es, básicamente, un programa que es interpretado por un navegador. El lenguaje de programación web es un consolidado de HTML, CSS y javascript.

Casi inmediatamente, se vió la posibilidad de generar páginas web usando otros lenguajes de programación, como C, Perl o Java. Después de todo, se trata de texto.

Las páginas web generadas por otros programas se llamaron dinámicas, porque podían cambiar en respuesta a la entrada del usuario. En contraposición, las páginas web no dinámicas se denominan estáticas.

Sin embargo, comparado con hacer una página web directamente, hacer una página dinámica supone un tramite mayor. El diseño de página estática se suele fragmentar para ser reconstruido con un programa. Si uno lo mira de cierta distancia, es código de cierto lenguaje con HTML insertado.

Se hizo así por un tiempo, pero luego se vió más conveniente insertar, en las páginas estáticas, la parte dinámica que se requería, luego usar un programa para resolver esos bloques dinámicos, y finalmente enviar el resultado al navegador. Es decir, HTML con código de otro lenguaje insertado. Básicamente, ese es el esquema que usan ASP, JSP y PHP.

Web, OOP y Procedural
La diferencia entre alternativas como JSP y PHP es cómo se resuelven los bloques dinamicos insertados en la página. Los primeros usan Java, un lenguaje OOP, y los segundos usan PHP, un lenguaje interpretado, básicamente.

Normalmente OOP permite expresar una solución en términos más simples que la alternativa procedural. Sin embargo, en el mundo web, este poder no ha significado mucha diferencia. De hecho, la web está más poblada de soluciones procedurales.

Un purista OOP podría elegir OOP simplemente por ser OOP y porque supone que si es mejor para ciertos casos es mejor para todos los casos.

Sin embargo, OOP es simplemente una forma de resolver un problema. Y su poderío limitado en la web puede ser algo interesante de ver para aprender de ello.

Liberando la web
Me parece que algunas aproximaciones tratan de forzar el desarrollo web hacia una cierta forma de trabajo, ignorando partes de su naturaleza.

Por ejemplo, tratan a una página web como si fuera simplemente una vista e implementan, en su propia versión, algunas de las características que ya tiene presente.

De ese modo, se puede lograr una forma de trabajar uniforme y estandar, similar a la que se logra en otros entornos no web, pero se obliga a los programadores a redefinir artificiosamente lo que la página es.

Pero una página web es un programa intérpretado. Quizás haya modos de aprovechar ese hecho en lugar de tratar de negarlo o limitarlo.

Quizás sería conveniente reconsiderar el modo en que se vuelve dinámica una página. Insertar código entre las etiquetas puede llegar a complicar el conjunto. Eso, en javascript, se resolvió usando unobstrusive javascript, que permite aislar el código en un lugar determinado y que actúe sobre la página desde afuera. Entonces, tal vez se podría hacer algo similar con los otros lenguajes que corren en el servidor. Unobstrusive PHP, unobstrusive JSP, etc. Lograr actuar sobre una página sin tocar su fuente estática.

Pienso que, de ese modo, el desarrollo HTML/CSS/Javascript se podría realizar con toda la libertad e innovaciones que son parte de su naturaleza. Y las partes dinámicas podrían ser resueltas usando el framework que mejor se adecúe al lenguaje que se utilice, pero aparte, en su propio ambito. Respetando el ámbito HTML/CSS/Javascript y tratando de complementar, potenciar, lo que las páginas ya son.

uphp para Drupal

En días recientes, navegando por Internet, me topaba con las opiniones de algunos desarrolladores sobre Drupal.

Comparado con otros frameworks, como los tipo MVC, CakePHP o similares, Drupal es raro. Brillante, pero raro. No es MVC y se apoya, más bien, en una arquitectura que usa hooks para permitir la colaboración de los módulos que se instalen.

Drupal tiene su modo particular de hacer las cosas y cuesta un poco acostumbrarse. A su modo de tratar los formularios, de hacer los temas, de intervenir en el flujo.

Sin embargo, el hecho es que Drupal está floreciendo más rápido que otros frameworks.

Muchos puristas de OOP critican que no use objetos, aunque Drupal dice que implementa los conceptos de OOP de modo diferente.

Quizás sea eso. Que Drupal ofrece una forma diferente de hacer las cosas que, una vez que se aprenden, ayuda a ser más colaborativo y productivo.

Pero, si uno tiene un sistema modelado en OOP tradicional, puede encontrar algunos inconvenientes para pasarlo a Drupal.

Aunque me ha ayudado mucho, Drupal tampoco tiene una forma que me haga sentir completamente cómodo.

Drupal tiene un sistema de tablas que usa para funcionar. Una de las tablas vitales es node. O, al menos, era lo que yo pensaba.

Resulta que node era una tabla opcional que se volvió obligatoria en algún momento del tránsito de la versión 4 a la 5.

¿Sería posible un Drupal sin node? ¿Sería posible un Drupal sin base de datos?

Parece que hay iniciativas al respecto. Aunque node es la base para luego poner CCK y Views, dos de sus módulos más destacados, hay quienes piensan que fue un error hacer que node se volviera obligatorio y que eso se podría corregir (Make Node module optional).

Inspirado por esa posibilidad, traté de ver si podría lograr que Drupal procesara archivos HTML sin necesitar usar tanto la base de datos para ello. Creé un módulo llamado html con la idea de que procesara los archivos que colocara en sites/default/html. Fui incorporando ideas de uphp y, poco a poco, me di cuenta que, en realidad, estaba portando uphp hacia Drupal.

uphp tiene la idea de empezar el desarrollo web con páginas estáticas e ir incorporándole comportamiento dinámico desde afuera, a la manera de unobstrusive javascript. En javascript, jQuery ayuda en eso. En PHP, es QueryPath.

La forma Drupal de hacer las cosas ha sido una inspiración al desarrollar uphp. No me considero un experto en Drupal, sino más bien un principiante, así que me sorprendió que uphp pudiera incorporarse de modo tan natural a Drupal. Sin estudiar mucho las cuestiones del core de Drupal, parece que lo que había imaginado resultó bastante similar.

Así que el módulo pasó a llamarse uphp. Los archivos estáticos se colocan en sites/default/files/html.

Me pareció que podría ser de utilidad a la comunidad y he aplicado para ver si es aceptado como proyecto en drupal.org.

Mientras tanto, he subido el archivo al repositorio de uphp en SourceForge.

Primera anotación

uphp es la búsqueda de un modo de desarrollar web, donde el código afecta el contenido pero se mantiene aparte, y el programador puede aplicar efectivamente las técnicas que ya conoce.

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/