viernes, 20 de mayo de 2011
lunes, 16 de mayo de 2011
Programando Web
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.
miércoles, 11 de mayo de 2011
uphp para 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.
Suscribirse a:
Entradas (Atom)