Entradas

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

Acceder a los valores de un nodo con javascript

Imagen
Una forma simple de hacer esto, es a través de Drupal.settings , que es un objeto siempre disponible. Para agregar el nodo a Drupal.settings , lo hago en alguna función adecuada, por ejemplo en la implementación del hook_form_alter() , ya que allí se hacen las alteraciones de los formularios de edición de nodos. Por ejemplo: function mymodule_form_alter(&$form, &$form_state, $form_id) {   switch ($form_id) {     case 'my_node_form':       ...       $node = node_load($form['nid']['#value']);       // port to javascript       if ($node) {         drupal_add_js(array('node' => $node), 'setting');       }       ...       break;     ...   } } Luego, en algún javascript que se invoque para el tipo my_node , se puede usar algo como:   var node = Drupal.settings.node;   var nid = Drupal.settings.node...

Resolviendo el cambio de alias con views_customfield

Imagen
Views Custom Field  es un módulo que permite colocar PHP como contenido de un campo de una vista. Normalmente, uno usa la variable $data para acceder a los valores de los campos que se hayan definido. Por ejemplo, $data->nid permite obtener el valor de nodo y haciendo print_r($data) uno puede explorar otros valores que usar. Pero hay un problema con los valores de los campos CCK. El nombre de los campos que contienen sus valores en $data corresponden a aliases que no son constantes. Por ejemplo, cuando usa filtros expuestos, podrá encontrar que ese nombre de campo en $data cambia según qué filtro esté aplicando. Una forma de solucionar esto es usar $this->view , también disponible, para obtener el alias adecuado en cada caso. Es decir, en lugar de usar $data->some_field_alias usar $data->{$this->view->field['field_id']->field_alias} Este es un ejemplo real: <?php $cliente_nid = $data->{$this->view->field['field_client_nid'...

Aplicando un patch en Windows

Imagen
El comando patch, disponible en Linux, usualmente no está disponible en Windows. Cuando uno quiere aplicar algún patch, suele encontrar una traba de solución no tan fácil. En lugar de las recomendaciones de instalar Cygwin, o algo parecido, alguna vez use Aptana (un derivado de Eclipse) para aplicar un parche. Hoy estoy instalando Simpletest y la documentación indica aplicar  patch -p0 < path/to/simpletest/D6-core-simpletest.patch y ya no recuerdo cómo lo hice con Aptana :-S Tampoco quisiera instalar Cygwin sólo para eso. Esta vez, noto que tengo instalado Git para Windows ( https://git-scm.com/download/win ), hago click derecho sobre el directorio drupal y elijo Git Bash Here . Hago patch --help para comprobar que cuento con el comando y luego: $ patch -p0 < sites/all/modules/simpletest/D6-core-simpletest.patch patching file `install.php' Hunk #1 succeeded at 19 (offset -1 lines). patching file `includes/bootstrap.inc' Hunk #1 succeeded at 1111 (offset -1 li...

Generación modular de HTML

Imagen
Actualmente, cuando desarrolla un sitio usando cierto framework, no lo puede modificar con otro. Si está metido en esto, puede parecer obvio y hasta natural. Pero, si lo vemos en perspectiva, es algo así como una limitación por diseño. Algo que se podría mejorar. Lea el artículo original en  Puroguramu: Generación modular de HTML

Redirigir, excepto si se está recuperando contraseña

Imagen
El requerimiento es que los usuarios logueados sean redirigidos a la página proyectos-nuevos . Eso se puede implementar usando actions/triggers . Es decir, el action redirigir a proyectos-nuevos cuando ocurre el trigger login del usuario. Cuando un usuario solicita recuperar su contraseña, se le facilita un enlace que conduce a una página de acceso provisional y luego, normalmente ocurre una redirección a la edición de su cuenta. Sin embargo, la redireccion con actions/triggers interfiere con esto y conduce también a este caso hacia proyectos-nuevos . Para solucionarlo, es mejor usar el módulo rules . Instalado rules, en  admin/rules/trigger se puede agregar una nueva regla que conduzca a proyectos-nuevos cuando ocurra el login. Produce el mismo efecto que al usar actions/triggers, incluso el de interferir con la redirección de recuperación de contraseña. Para prevenir la redirección en ese caso, se puede agregar una condición PHP a la regla: if (arg(0) == 'use...