Frameworks y Drupal

Framework... con qué se come?
Recuerdo que, cuando empecé a programar en PHP, navegando por Internet encontraba algunas veces la palabra framework.

Primero pasaba de largo, pensando que todavía estaría lejos el momento en que estuviera listo para abordar algo que, seguramente por complejo, no había visto en los tutoriales o libros introductorios de PHP. Quizás deberían hablar más sobre eso.

Alguna vez bajé un framework e intenté hacer algo, pero lo dejaba después de un rato, frustrado por no entender dónde poner las cosas para lograr las cosas que quería.
Ya había desarrollado algunas aplicaciones web, principalmente usando el JSP del mundo Java. Con PHP todo era similar pero más simple y ligero, más directo y más rápido, y me empezaba a gustar. Pero no entendía lo de los framework.

Luego, estuve encargado del desarrollo de una aplicación web que debía ser hecha con Struts 1.1. Tardé como un mes en darme cuenta que el framework determinaba una secuencia de trabajo. Eso era. Por eso se llamaba framework. Quizás suene gracioso, pero sinceramente pienso que muchas personas usan frameworks sin entender realmente lo que son.

Después, aprender Struts en Java me ayudó a que fuera luego más fácil volver a intentarlo en PHP, y aprendí CakePHP y otros frameworks más.

Ahora, después de haber desarrollado sin esos frameworks y con ellos, en solitario y en equipo, sin y con estándares declarados, y después de haber reflexionado algún tiempo, tengo algunas ideas y opiniones sobre el tema.

Todos son frameworks
Un framework es, básicamente, una forma de trabajar.

Muchas personas piensan, casi de inmediato, que ser framework es algo exclusivo de Struts, CakePHP, CodeIgniter, Zend, o similares, publicados en un site, con enlaces para descargar y documentación que leer y practicar.

Esos son frameworks famosos pero, en realidad, cada persona y cada equipo de trabajo determina un framework cada vez que hace un desarrollo. Lo que funciona bien se puede volver a usar y lo que no funciona bien se puede probar de otro modo. Con el tiempo se van incorporando nuevos casos y se va puliendo el esquema que, descubrimos un día, se llama framework.

Incluso cuando se usa un framework estandar se determina otro framework al desarrollar, ya que cada equipo lo puede usar de diferente modo para resolver el mismo problema.

Pienso que un framework debería ser entendido de un modo amplio. No sólo como una manera de organizar el código, sino como la manera de trabajar de la gente sobre ese código. Porque ambas cosas están relacionadas. Por ejemplo, si un equipo no comprende MVC, puede tomar un framework MVC como base y en el proceso de desarrollo desfigurarlo hasta llegar a una solución con las mismas, o más, complicaciones de un proyecto no-MVC.

Es decir, un framework tiene un workflow asociado.

Adoptar un framework significa aprender a producir de modo sostenible código que siga cierto esquema. Aprender cómo se debe ver el código, pero a la vez también cómo podría ser un flujo de trabajo que permita hacerlo indefinidamente.

Qué vendría a ser Drupal?
Digamos que desarrollas aplicaciones web habitualmente. Sería bueno que pudieras agregar y quitar funcionalidades fácilmente. Que tuviera una naturaleza modular. ¿Cuántos proyectos has desarrollado que permita incorporar una funcionalidad de ese modo?.

Además, sería muy bueno que esas cosas se pudieran hacer desde la misma interfaz web. ¿Cuantos proyectos has desarrollado que permitan instalar y desinstalar funcionalidades desde la misma página?

Si pudieras hacerlo, llegarías a algo similar a Drupal. Luego, podrías empezar a desarrollar módulos para manejo de usuarios, manejo de contenido, acceso a contenido, subir imágenes, etc. Pero, un momento, Drupal ya tiene módulos para eso y mucho más.

Entonces, incluso aunque pudieras hacer por tí mismo una aplicación a la Drupal, es bastante conveniente usar Drupal y descubrir qué otras cosas más podemos hacer con él.

La web marcó un hito cuando permitió enlazar páginas de información, democratizando la publicación. El wiki marcó otro hito cuando permitió hacerlo usando la misma página para editar, democratizando un poco más las cosas.

Actualmente, gran parte de las aplicaciones web se desarrollan de modo similar a como antes se desarrollaban las páginas web; usando editores externos y profesionales especializados. Pero Drupal nos está acercando más a la posibilidad de hacer el desarrollo completo usando la misma página, y que dependamos menos de otros profesionales para lograr la aplicación web que queremos.

Creo que no hay muchos frameworks que se preocupen de proveer un desarrollo modular o desde la misma página.
Posiblemente, en el futuro, vayan apareciendo más entornos a la Drupal, o tratando de ser más drupables, de modo similar a la explosión web, o la explosión de wikis que hubo después que apareció el primero.

Sí, también me parece buena idea. Así que desde hace un tiempo estoy estudiando Drupal. Felizmente hay bastante material para consultar y gente dispuesta a darnos una mano.

Ya puedo hacer sites con cierta funcionalidad, pero aún no me siento seguro. En especial con el desarrollo de módulos. Me suelo sentir como cuando intentaba aprender MVC por primera vez. Un poco perdido y sin ningun texto ni nadie con una explicación simple y clara.

Entonces, voy escribiendo esta bitácora de mi exploración en Drupal, la Drutacora. Quizás a alguien le ayuden estas notas en su propio viaje.