Translate to

Buscar

Cargando...

24 de julio de 2012

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.
Quisiera que fuera más fácil de usar. Que tuviera un core más simple, más minimo, sin base de datos. Que no me obligara a aprender nuevas formas de hacer lo que ya se puede hacer con html (y a cambiarlas con una nueva versión). No tener el sentimiento de llevar un montón de lastre, sino sólo lo que quiero. Que pudiera ser una bicicleta si quiero, o un auto, o un camión. Si quiero, que no me obligue. Que me deje ver qué está ocurriendo debajo. Que sea más fácil de ver cómo me puede ayudar. Que no solo sea elegible porque lo dice alguien como whitehouse.gov sino porque técnicamente también sea bueno y al usarlo se sienta bien.
Quisiera que pudiera ser mejor.

Referencias:

5 de julio de 2012

Pensando con Drupal

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 curva con una bicicleta que con un camión. Si hay que ir por la autopista, llevando cierta carga, es más llevadero en camión. Si hay que ir a campo traviesa, puede ser más rápido en bicicleta.

Hoy me plantearon un problema y automáticamente empecé a pensarlo en términos de Drupal. Visualicé un malabarismo con los módulos. Mi amigo, que no conoce Drupal ni PHP, pero tiene nociones de programación web, me planteó una idea simple que al comienzo, por inercia, no me pareció razonable. Pero quizás tuviera razón. Reflexioné un rato. Y cuanto más lo pensaba más natural me parecía su propuesta. Luego de un rato, despejado de mi prejuicio pro drupal, acepté el hecho que con PHP simple podríamos hacerlo mejor. Al menos en este caso.

Si, Drupal no es para todo. La misma gente de Drupal lo acepta. Pero mi reflexión también apunta al hecho de cuán sencillo puede ser acostumbrarse a resolver un problema en términos de cierto framework o esquema mental.

Es bueno contar con alternativas.

Ojalá pudiera ser como ir en bicicleta :-)

8 de junio de 2012

Bloques con id descriptivos

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;
  }
}
...

block.tpl.php
<div id="<?php echo block_id($block); ?>" class="clear-block block block-<?php print $block->module ?>">

<?php if (!empty($block->subject)): ?>
  <h2><?php print $block->subject ?></h2>
<?php endif;?>

  <div class="content"><?php print $block->content ?></div>
</div>

En mi caso, usando Omega theme, no había un block.tpl.php por default, así que lo copié de themes/garland/.

Una alternativa al uso de ids descriptivos, mencionado en el punto anterior, es usar classes descriptivas. Para eso se puede usar el módulo Block Class. Clases específicas se podrán asignar en la configuración de un block. Por ejemplo, si se asigna la clase logo, luego se podrá localizar al bloque con .block.logo.

5 de junio de 2012

La forma Drupal

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 :-)

27 de marzo de 2012

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 momento?
  • ¿Vale la pena probar Drupal 7, que probablemente sea dejado de lado cuando llegue Drupal 8, o mejor explorar otras alternativas por ahí?
  • ¿Drupal 7 ha sido realmente necesario para comunidad? ¿La ha fortalecido?
  • Quizás el comité ha preferido no ver ciertas consecuencias de los saltos. Quizás el comité quisiera que lo que pretende es el futuro se vuelva realidad, y que lo haga la comunidad.
  • Quizás la comunidad tenga la respuesta, si se le permitiera vida propia.
  • Quizás la comunidad se abra paso, de algún modo, como el agua. Si no en Drupal, en algún otro lugar.
  • Drupal 8 sería un llamado a continuar. Pero atrás parece sonar el eco de los buenos tiempos que ya se van.

Más artículos