Entradas

Drupal sí, drupal no

Ciertamente puedo tener sentimientos encontrados respecto a Drupal. Por un lado, muestra una forma rara de hacer las cosas, resulta largo de aprender, la configuración guardada en base de datos dificulta el desarrollo y seguimiento de versiones de sites , hay copyrights raros en un proyecto open source, migraciones masivas empujadas desde arriba, el sentimiento creciente de que el auto armable en casa se va convirtiendo en un trailer... Por otro lado, permite armar cosas modularmente, tiene una comunidad entusiasta, es adoptada como solución por entidades importantes, la esperanza de que tal vez las buenas intenciones lleven a una versión ligera que permita apreciar mejor su encanto, y que la comunidad sea más empujada desde abajo, las diferencias mejor admitidas... Quizas piense alguien que soy un soñador, pero no soy el único... 8-P si uno busca en Google, puede encontrar puntos de vista opuestos a Drupal, total o parcialmente. Yo no soy opuesto, ni estoy a favor ciegamente.

Pensando con Drupal

Imagen
Me estoy dando cuenta de que cuando me consultan por el desarrollo de un site, empiezo a pensar en cómo lo puedo hacer en términos de Drupal. Hacer un site típico en Drupal cuesta un poco de resolver las primeras veces pero luego es bastante más llevadero. Cuando hay algo nuevo que implementar con Drupal, es similar, cuesta un poco al comienzo pero luego se hace más llevadero. Y es más fácil si existe un módulo que nos acerque a la solución. Con Drupal y otros frameworks pasa eso. Aunque ya sepamos cómo se hace algo tenemos que volverlo a aprender en términos del framework. Pero lo hacemos porque nos abre las puertas a muchas cosas que aún no sabemos. Sin embargo, eso no significa que todas las soluciones en términos de Drupal sean más simples, eficaces o elegantes que las que podríamos hacer sin él. Pero es un precio que se paga por el confort. Es como cuando se toma un vehículo para viajar. Cuanto más grande y pesado tiende a ser menos maniobrable. Es más fácil dar una cu

Bloques con id descriptivos

Imagen
En Drupal , los bloques suelen tener id numéricos, lo que dificulta el mantenimiento de los estilos que se les aplica (el id numérico de un block puede cambiar si se lo elimina y vuelve a crear, por ejemplo). Puede ser más conveniente usar id descriptivos. Para eso, se puede aplicar algo como: template.php ... /** * Devuelve un id textual para el block * http://www.bluepiccadilly.com/2011/12/give-your-drupal-blocks-more-descriptive-html-id-attribute */ function block_id (&$block) { $info = module_invoke($block->module, 'block', 'list'); if ($info[$block->delta]['info']) { $block_id = 'block-' . $block->module . '-' . $info[$block->delta]['info']; $block_id = str_replace(array(' ', '_'), '-', strtolower($block_id)); return preg_replace('/[^\-a-z0-9]/', '', $block_id); } else { return 'block-' . $block->module . '-' . $block->delta;

La forma Drupal

Imagen
Al elaborar un site, a veces me pregunto por qué usar un framework como Drupal. Para hacer algo, primero veo si puedo hacerlo con los módulos que tengo, si no, veo si hay módulos que me acerquen a lo que se necesita, si no, programo lo que se necesita. Otros desarrolladores prefieren usar un framework que les permita programar con soltura lo que se necesita. También pueden revisar antes si ya tienen algo similar o si alguien más lo tiene. ¿Cuál es la diferencia? La forma en que Drupal tiene las soluciones. Quizás no sea perfecta, ni simple, ni elegante, ni eficiente, pero es algo como un estándar. Hay una cierta forma de reutilizar soluciones previas. Puedes ponerles un nombre y publicarlas de modo que otros también puedan usarlas. Hay algo en la forma Drupal que tiene su encanto. Podría ser mejor, pero algo es algo :-)

Divagando en Drupal

Me parece que: Drupal tiene una idea brillante en su forma de proveer extensibilidad. Con el tiempo: los desarrolladores que notaron eso formaron una comunidad. la fama de Drupal fue aumentando. el desarrollo con Drupal se volvió una oportunidad de negocio. Cuando se hizo notorio el negocio, se hizo notorio el comité que guía la evolución de Drupal. La evolución de Drupal no es directamente controlada por la comunidad. Es hecha por la comunidad, pero no necesariamente para la comunidad. El comité motivó a la comunidad para que hiciera algunos saltos evolutivos. Quizás la versión más exitosa ha sido Drupal 6. Drupal 7 parecía un salto evolutivo natural, sin embargo quizás estuvo más inspirado en el desarrollo de la iniciativa Acquia. Saltar de Drupal 6 a Drupal 7 no ha resultado algo fácil. Drupal 8 buscaría volver a Drupal algo más genérico. ¿Vale la pena gastar energía en saltar de Drupal 6 a Drupal 7, o es mejor guardarla para saltar a Drupal 8 cuando llegue el moment

HTML + Javascript para usar cualquier framework

Lea el artículo original en Puroguramu .

Por qué la Programación Orientada a Objetos es mala para Drupal

artículo de Matt Buttcher (2010/10/13), traducción libre de Antonio Kobashikawa Nota de traductor : Aunque Drupal se ha convertido en un movimiento poderoso, parece que, en el interés por capitalizar algunos negocios asociados, se han tomado decisiones que están distanciando al producto de sus objetivos primarios para la comunidad. Algunas personas han estado notando eso desde hace algún tiempo y me parece interesante el tema. He conducido o contribuido a docenas de proyectos Open Source. Y todo mi código ha sido siempre Orientado a Objetos, con una excepción. Esa excepción es Drupal. Java, Python, PHP, y aún OO Perl... soy un desarrollador que teje con la lana del OO. Así que esto puede sonar chocante para cualquiera que me conoce, pero mi argumento es que la OO es mala para Drupal. Créame que decirlo no es algo notable en mi vida de desarrollador. Me siento como si le dijera a mi niño que debe faltar al colegio, sólo porque tal nivel de sofisticación no es necesaria en su vida