Damián Culotta » Php

Cómo crear una clase para el Shell en Magento

Damián — Mon, 25 Apr 2011 07:00:28 +0000

Cuando pensamos en módulos para Magento nos quedamos, normalmente, con agregar funcionalidad para el frontend o para el backend.

Creo que cuando pensamos en un módulo debemos imaginarnos los cuatro posibles entornos para su aplicación. Por los cuatro entornos me refiero:

Frontend o tienda propiamente dicha.
Backend o administración.
API.
Consola.

Si bien ésta división puede parecer arbitraria, éstas serán las posibles puertas de entrada que normalmente utilicemos (dependiendo sobre si nos toca ser usuario, administrador, desarrollador o el encargado del mantenimiento; o todo).

Claro está que no todos los módulos requieren funcionalidad en los cuatro entornos, pero en muchos casos deberíamos cuidar las formas y proveer de herramientas para cada caso.

En mi caso, desde hace ya un buen tiempo, me ha tocado desarrollar unas cuantas integraciones que importan o exportan información. Normalmente, con procesos manejados a través del Cron de Magento.

Uno de las situaciones con las que nos vamos a encontrar cuando trabajemos con módulos que funcionan con un cronjob, es la de la prueba de ejecución. Está claro que podemos programar la tarea para que se ejecute y esperar a que suceda. Luego de la quinta prueba es muy probable que empecemos a perder un poco la paciencia.

Lo que vamos a ver hoy es cómo crear una clase para el shell respetando el estilo de la plataforma. Si bien podemos hacerlo por fuera de éstos lineamientos, vamos a tratar de ser lo más respetuosos posible. La idea es lograr tener siempre extensiones prolijas para que puedan ser reutilizadas y no nos generen conflictos con otras extensiones (o al menos que esos casos sean los menos posibles).

Para seguir con los ejemplos, y partiendo de un punto que cualquiera podría replicar para partir desde el mismo lugar, voy a seguir con mi módulo Dc_Test, creado con el generador de módulos.

Ahora bien, nuestro modulito nos provee ya de la grilla y el formulario para cargar datos en el backend.

Más allá que en éste caso no tenemos motivo aparente para tener funcionalidad en la consola, vamos a pasar por alto ésta cuestión y pensemos que necesitamos poder tener información sobre los datos manejados por éste módulo.

Lo primero que tenemos que hacer es crear nuestra clase que, para mantener la lógica, vamos a llamar Dc_Shell_Test y la vamos a guardar en el archivo /shell/test.php.

La versión más simple de nuestra clase contará con dos métodos: run() y usageHelp(). Más allá de lo obvio, el método usageHelp es el que usaremos para brindar información sobre el uso de la clase.

Un ejemplo de su contenido podría ser:

public function usageHelp() {
    return <<;
}

Hasta ahora, dado que nuestra clase no tiene acciones posibles, sólo podemos mostrar que la ayuda nos permite invocar a la ayuda (si, muy Inception style).

El otro método posible, en nuestra adolescente clase, es run(). De más está decir que éste es el método que será invocado y que será el responsable de ejecutar la o las acciones que desarrollemos.

Aquí podemos aplicar dos formas para invocar a las acciones.

La primera, para el caso más sencillo, sería la siguiente.

public function run() {
    if ($this->getArg('my_action')) {
        //Tareas a realizar por la acción my_action
    } else {
        echo $this->usageHelp();
        exit(1);
    }
}

En éste momento, nuestra clase se debe ver de la siguiente forma. (Nótese que agregué información en el método usageHelp() para describir nuestra acción).

class Dc_Shell_Test {
    public function run() {
        if ($this->getArg('my_action')) {
            //Tareas a realizar por la acción my_action
        } else {
            echo $this->usageHelp();
            exit(1);
        }
    }
 
    public function usageHelp() {
        return <<;
    }
 
}

La clase ya es funcional, pero a nuestro archivo le faltan aún tres líneas.

Primero, debemos hacer un include para la clase abstracta que Magento utiliza para el Shell.

Luego, al final de nuestro archivo otras dos líneas que nos van a instanciar la clase y luego a ejecutarla.

El ejemplo completo debe verse así.

require_once 'abstract.php';
 
class Dc_Shell_Test extends Mage_Shell_Abstract {
 
    public function run() {
        if ($this->getArg('my_action')) {
            echo "Acción de my_action\n";
        } else {
            echo $this->usageHelp();
            exit(1);
        }
    }
 
    public function usageHelp() {
        return <<;
    }
 
}
 
$shell = new Dc_Shell_Test();
$shell->run();

Ahora si, nos vamos a la consola, y dando por sentado que estamos en el directorio correcto, hacemos nuestra primera prueba.

php test --my_action

Nos devolverá.

Acción de my_action

Si en cambio pasamos un parámetro no soportado.

php test --my_test

Tendríamos que obtener lo siguiente.

Usage:  php -f test.php -- [options]
  --myaction          Test action
  --help              This help

Como ven, es una lógica muy sencilla. Básicamente, si el nombre del argumento coincide con uno de los definidos como acción, se ejecutará. Caso contrario, se muestra la ayuda.

Si tuviéramos varias acciones, podemos, o bien tener varios if else if y toda la lógica dentro del método run(), o bien hacer un poco más ordenada nuestra clase y separar cada acción en métodos independientes y modificar un poquito a run().

A manera de ejemplo, vamos a suponer que tenemos 5 acciones posibles, a las que llamaremos: accion1, accion2, accion3, accion4 y accion5.

Para cada acción vamos a crear un método privado. Sólo para el ejemplo, probemos con:

private function accion1() {
    echo "Acción 1\n";
}
 
private function accion2() {
    echo "Acción 2\n";
}
 
private function accion3() {
    echo "Acción 3\n";
}
 
private function accion4() {
    echo "Acción 4\n";
}
 
private function accion5() {
    echo "Acción 5\n";
}

Ahora vamos a cambiar un poquito a run() para evitarnos una lista interminable de if else if.

No sólo vamos a pasar un argumento, sino que vamos a asignarle un valor.

public function run() {
    $action = $this->getArg('my_action');
    if (!empty($action)) {
        $method = $action;
        if (method_exists($this, $method)) {
            $this->$method();
        } else {
            echo "Action $action not exists\n";
            echo $this->usageHelp();
            exit(1);
        }
    } else {
        echo $this->usageHelp();
        exit(1);
    }
 
}

Lo que cambia ahora es que además de validar que exista el parámetro, vamos a tomar el valor del argumento y lo vamos a utilizar para invocar uno de nuestros métodos.

Si el método no existe, notificamos y mostramos la ayuda. (Siempre que agreguemos nuevas acciones tendríamos que agregar la correspondiente descripción en la ayuda).

La clase completa debería verse así.

class Dc_Shell_Test extends Mage_Shell_Abstract {
 
    public function run() {
        $action = $this->getArg('my_action');
        if (!empty($action)) {
            $method = $action;
            if (method_exists($this, $method)) {
                $this->$method();
            } else {
                echo "Action $action not exists\n";
                echo $this->usageHelp();
                exit(1);
            }
        } else {
            echo $this->usageHelp();
            exit(1);
        }
    }
 
    private function accion1() {
        echo "Acción 1\n";
    }
 
    private function accion2() {
        echo "Acción 2\n";
    }
 
    private function accion3() {
        echo "Acción 3\n";
    }
 
    private function accion4() {
        echo "Acción 4\n";
    }
 
    private function accion5() {
        echo "Acción 5\n";
    }
 
    public function usageHelp() {
        return <<;
    }
 
}

Con ésta modificación, vamos a cambiar la forma de pasar los parámetros. Si quisiéramos llamar a la Acción 3, lo haríamos de ésta forma.

php test.php --my_action accion3

Y obtendríamos éste resultado.

Acción 3

Y si enviáramos un parámetro incorrecto, por ejemplo: php test.php –my_action accion6, deberíamos obtener el mensaje de nuestra ayuda.

Action accion6 not exists
Usage:  php -f test.php -- [options]
 
  --my_action accion1     Acción 1
  --my_action accion2     Acción 2
  --my_action accion3     Acción 3
  --my_action accion4     Acción 4
  --my_action accion5     Acción 5
  --help                  This help

Ahora si, ya tenemos una forma prolija y ordenada de realizar acciones en Magento desde la consola.

A lo mejor te interese leer

Collabtive-CI 0.6.5.2

Damián — Sun, 17 Apr 2011 03:01:54 +0000

Al comienzo es fácil mantener el ritmo, así que vamos a aprovechar la inercia.

Versión 0.6.5.2 de Collabtive-CI con otro cambio referente a las tareas. En ésta oportunidad, agregué la posibilidad, opcional, de cargar para una tarea la cantidad de tiempo estimado que va a llevar.

La idea será avanzar sobre el control de tiempo para luego poder medir la estimación contra el tiempo real demandado.

A diferencia de las prioridades, éste campo no es obligatorio al momento de crear la tarea.

Como ya he dicho, ante cualquier error o comentario, éste es el link del Gestor de Incidencias de Collabtive-CI.

A lo mejor te interese leer

Collabtive-CI 0.6.5.1

Damián — Sat, 16 Apr 2011 21:10:17 +0000

El primer set de cambios ya se encuentra publicados bajo la versión 0.6.5.1 de Collabtive-CI.

Los cambios implementado son:

Cambios en las plantillas de mail, enviando ahora mayor información al agregar o editar una tarea.
Correcciones de traducciones.
Se agregó la constante CL_BRANCH_VERSION y se implementó su uso junto a CL_VERSION en el footer.
Creación automática de las carpetas files y templates_c al momento de la instalación.
Se quitó el indicador de usuarios online y el chat de la barra lateral.
Se restauró el calendario en la barra lateral.
Se muestran todos los proyectos a los cuales el usuario está asociado, para dar la posibilidad de cambiar de proyecto si tener que pasar por el Escritorio.
Se implementaron prioridades para las tareas.

El cambio más significativo, y del cuál se ha hablado bastante en los foros, es el de las prioridades.

De ésta forma puede verse en el Escritorio.

El listado de tareas dentro del proyecto también muestra la nueva columna.

La nueva columna funciona de la misma forma que las demás. Podemos utilizarla como criterio para ordenar la lista.

En la creación (o edición) de tareas, tenemos el dropdown en el cual debemos seleccionar el tipo de prioridad.

Para finalizar, el cambio en la barra lateral.

Ante cualquier error o comentario, pueden usar el Gestor de Incidencias de Collabtive-CI o comunicarse a través del blog.

A lo mejor te interese leer

Collabtive y Collabtive-CI

Damián — Sat, 16 Apr 2011 21:00:44 +0000

Desde hace ya un buen tiempo utilizo Collabtive para ~~intentar~~ gestionar proyectos, tareas, ideas, etc. Es una herramienta bastante cómoda y sencilla (tanto para trabajar de forma individual como grupal).

Básicamente, la aplicación presenta una pantalla general en la que veremos los proyectos en los que estamos involucrados y todas las tareas que tenemos asignadas.

A nivel proyecto, la pantalla principal nos permite hacer la carga de tiempo consumido para una tarea, ver el calendario y los logs del mismo.

La lógica que presenta la herramienta es bastante sencilla.

Creamos un proyecto.
Dentro del mismo podemos (o no) tener hitos (si, suena raro para milestone).
Luego creamos listas de tareas que pueden o no estar asociadas a un milestone.
Dentro de cada lista de tareas creamos nuestras tareas.

Además, por cada proyecto podemos cargar archivos y dejar mensajes que pueden ser contestados. Cuenta también con un sencillo chat y con un buscador.

Toda ésta introducción no es precisamente para hablar del proyecto original, sino que debido al ritmo con qué se ha venido actualizando en el último año, publiqué mi versión modificada a través de GitHub.

Con ésta versión sólo busco hacer públicos los cambios que he implementado para mi, algunos por necesidad, otros en base a comentarios en los foros de Collabtive.

El nombre, Collabtive-CI, está relacionado con una idea a largo plazo, partiendo de la versión original. Además de darle mayores funcionalidades, hay una reescritura completa planificada.

Hasta que llegue ese punto voy a estar manteniendo compatibilidad 100% con el proyecto original.

Si alguien tiene ganas de probarlo y dar feedback, sugerir funcionalidades o avisar de bugs; puede dejar un comentario, enviar un mail o usar el Gestor de Incidencias del proyecto en GitHub.

A lo mejor te interese leer

Extendiendo la configuración gráfica del cron en Magento

Damián — Fri, 01 Apr 2011 07:00:40 +0000

Para evitar tener que lidiar con la configuración por xml, en Magento podemos crear la configuración gráfica para los cron jobs de nuestros módulos, de manera que estamos dando mayor flexibilidad al usuario y nos evitamos riesgos que podrían ocasionarse por una mala edición de los archivos.

Normalmente las opciones que nos ofrece la configuración suelen ser suficiente.

En otros casos, es posible que no nos alcance con sólo poder configurar una ejecución diaria, semanal o mensual. En éste esquema, nos estamos perdiendo la posibilidad de configurar la ejecución con repetición por horas o por minutos.

Para poder obtener esas opciones vamos a necesitar crear dos modelos para nuestro módulo, que serán los encargados de brindarnos esas nuevas posibilidades (y de paso vamos a arreglar otras que no funcionan desde la implementación original).

Lo primero será crear un nuevo set de opciones de frecuencia de ejecución. Para esto, podemos crear la siguiente clase (pensando que el módulo se llama Dc_Modulo): Dc_Modulo_Model_Config_Cron_Frequency, que estaría ubicada en /app/code/local/Dc/Modulo/Model/Config/Cron/Frequency.php.

La clase contendría lo siguiente.

class Dc_Modulo_Model_Config_Cron_Frequency
{
 
    protected static $_options;
 
    const CRON_MINUTELY = 'I';
    const CRON_HOURLY   = 'H';
    const CRON_DAILY    = 'D';
    const CRON_WEEKLY   = 'W';
    const CRON_MONTHLY  = 'M';
 
    public function toOptionArray()
    {
        if (!self::$_options) {
            self::$_options = array(
                array(
                    'label' => Mage::helper('modulo')->__('Minutely'),
                    'value' => self::CRON_MINUTELY,
                ),
                array(
                    'label' => Mage::helper('modulo')->__('Hourly'),
                    'value' => self::CRON_HOURLY,
                ),
                array(
                    'label' => Mage::helper('modulo')->__('Daily'),
                    'value' => self::CRON_DAILY,
                ),
                array(
                    'label' => Mage::helper('modulo')->__('Weekly'),
                    'value' => self::CRON_WEEKLY,
                ),
                array(
                    'label' => Mage::helper('modulo')->__('Monthly'),
                    'value' => self::CRON_MONTHLY,
                ),
            );
        }
        return self::$_options;
    }
 
}

Luego vamos a crear (o modificar) el modelo encargado de capturar los valores ingresados en la configuración para convertirlos en una expresión de tiempo cron.

Siguiendo el ejemplo, la clase podría llamarse Dc_Modulo_Model_Config_Cron_Process, la cual se encontraría en /app/code/local/Dc/Modulo/Model/Config/Cron/Process.php.

Aquí es donde vamos a insertar unas cuantas modificaciones y correcciones al modelo original ofrecido por Magento.

class Dc_Modulo_Model_Config_Cron_Process extends Mage_Core_Model_Config_Data
{
 
    const CRON_STRING_PATH = 'crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr';
    const CRON_MODEL_PATH = 'crontab/jobs/mi_modulo_mi_cron_job/run/model';
 
    protected function _afterSave()
    {
        $time = $this->getData('groups/cronjob_execution/fields/time/value');
        $frequency = $this->getData('groups/cronjob_execution/fields/frequency/value');
 
        $frequencyMinutely = Dc_Modulo_Model_Config_Cron_Frequency::CRON_MINUTELY;
        $frequencyHourly = Dc_Modulo_Model_Config_Cron_Frequency::CRON_HOURLY;
        $frequencyDaily = Dc_Modulo_Model_Config_Cron_Frequency::CRON_DAILY;
        $frequencyWeekly = Dc_Modulo_Model_Config_Cron_Frequency::CRON_WEEKLY;
        $frequencyMonthly = Dc_Modulo_Model_Config_Cron_Frequency::CRON_MONTHLY;
 
        $cronDayOfWeek = date('N');
        $cronDayOfMonth = date('j');
 
        $minutelyValue = null;
        if ($frequency == $frequencyMinutely) {
            $minutelyValue = '*/' . intval($time[1]);
        } else {
            $minutelyValue = intval($time[1]);
        }
 
        $hourlyValue = null;
        if ($frequency == $frequencyHourly) {
            $hourlyValue = '*/' . intval($time[0]);
        } else if ($frequency == $frequencyMinutely) {
            $hourlyValue = '*';
        } else {
            $hourlyValue = intval($time[0]);
        }
 
        $cronExprArray = array(
            $minutelyValue,
            $hourlyValue,
            ($frequency == $frequencyMonthly) ? $cronDayOfMonth : '*',
            '*',
            ($frequency == $frequencyWeekly) ? $cronDayOfWeek : '*',
        );
 
        $cronExprString = join(' ', $cronExprArray);
 
        try {
            Mage::getModel('core/config_data')
                ->load(self::CRON_STRING_PATH, 'path')
                ->setValue($cronExprString)
                ->setPath(self::CRON_STRING_PATH)
                ->save();
            Mage::getModel('core/config_data')
                ->load(self::CRON_MODEL_PATH, 'path')
                ->setValue((string) Mage::getConfig()->getNode(self::CRON_MODEL_PATH))
                ->setPath(self::CRON_MODEL_PATH)
                ->save();
        } catch (Exception $e) {
            throw new Exception(Mage::helper('modulo')->__('Unable to save Cron expression'));
        }
    }
 
}

El paso final es indicar en la configuración de system.xml, que para éste módulo estaría ubicado en /app/code/local/Dc/Modulo/etc/, que para la configuración utilice nuestros modelos.

En éste caso, la definición de estos campos quedaría de la siguiente forma.

 translate="label">
    >Start Time>
    >time>
    >1>
    >1>
    >0>
    >0>
>
 translate="label">
    >Frequency>
    >select>
    >modulo/config_cron_frequency>
    >modulo/config_cron_process>
    >2>
    >1>
    >0>
    >0>
>

Una vez aplicados estos cambios, nuestra opción de configuración debería verse de ésta forma.

Ahora veamos el resultado práctico de cada una de las configuraciones que ahora podemos aplicar.

Si configuramos la ejecución por minutos.

El resultado de ésta configuración será la siguiente expresión.

+-----------+---------+----------+--------------------------------------------------------+--------------+
| config_id | scope   | scope_id | path                                                   | value        |
+-----------+---------+----------+--------------------------------------------------------+--------------+
|      1041 | default |        0 | crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr  | */30 * * * * |
+-----------+---------+----------+--------------------------------------------------------+--------------+

Si la opción fuera por hora.

Obtendríamos ésta expresión.

+-----------+---------+----------+--------------------------------------------------------+--------------+
| config_id | scope   | scope_id | path                                                   | value        |
+-----------+---------+----------+--------------------------------------------------------+--------------+
|      1041 | default |        0 | crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr  | 0 */2 * * *  |
+-----------+---------+----------+--------------------------------------------------------+--------------+

Ahora, una de las opciones conocidas: una vez por día.

Nos devuelve lo que ya conocemos.

+-----------+---------+----------+--------------------------------------------------------+--------------+
| config_id | scope   | scope_id | path                                                   | value        |
+-----------+---------+----------+--------------------------------------------------------+--------------+
|      1041 | default |        0 | crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr  | 15 3 * * *   |
+-----------+---------+----------+--------------------------------------------------------+--------------+

Para el caso de la ejecución semanal.

Ahora si grabará correctamente el valor.

+-----------+---------+----------+--------------------------------------------------------+--------------+
| config_id | scope   | scope_id | path                                                   | value        |
+-----------+---------+----------+--------------------------------------------------------+--------------+
|      1041 | default |        0 | crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr  | 30 4 * * 5   |
+-----------+---------+----------+--------------------------------------------------------+--------------+

El último caso es el de la ejecución una vez por mes.

Luego de la corrección, ahora si, nos devolverá la siguiente expresión.

+-----------+---------+----------+--------------------------------------------------------+--------------+
| config_id | scope   | scope_id | path                                                   | value        |
+-----------+---------+----------+--------------------------------------------------------+--------------+
|      1041 | default |        0 | crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr  | 45 5 1 * *   |
+-----------+---------+----------+--------------------------------------------------------+--------------+

Si bien éste cambio nos permite una mejora sustancial en la configuración de un cron job, para crear configuraciones más avanzadas tenemos sólo dos opciones:

Configurar por xml la expresión de tiempo.
Habilitar un campo de texto en el cual el usuario ingresará la expresión como si lo estuviera haciendo en el xml.

A lo mejor te interese leer

Configuración gráfica para un cron job en Magento

Damián — Wed, 22 Sep 2010 03:17:12 +0000

Siempre que se habla de crear cron jobs para un módulo en Magento, se explica cómo configurar el crontab y el xml del módulo.

Si bien vamos a lograr el objetivo, esto siempre obliga a quien administra el proceso a estar editando un archivo y corrigiendo los tiempos de ejecución.

De ésta forma no sólo estamos ante una situación incómoda sino que, además, podríamos estar comprometiendo la integridad del módulo.

Voy a dar por sentado que ya nuestro cron job funciona como queremos y que hemos creado la configuración de otros parámetros del módulo. Sólo nos vamos a concentrar en agregar la configuración gráfica para la ejecución.

Ahora bien, el primer paso es crear un nuevo modelo que será el encargado de transformar los valores que ingresemos en la configuración a valores que el Cron Manager de Magento entienda.

Si bien no hay por qué seguir ningún estándar en particular, para éste tipo de modelos suele usarse la siguiente nomenclatura.

/app/code/local/Dc/Modulo/Model/Config/Cron/Proceso.php

Ahora bien, vamos a crear la clase.

class Dc_Modulo_Model_Config_Cron_Proceso extends Mage_Core_Model_Config_Data {
 
    const CRON_STRING_PATH = 'crontab/jobs/mi_modulo_mi_cron_job/schedule/cron_expr';
    const CRON_MODEL_PATH = 'crontab/jobs/mi_modulo_mi_cron_job/run/model';
 
    protected function _afterSave() {
 
        $time = $this->getData('groups/cronjob/fields/time/value');
        $frequency = $this->getData('groups/cronjob/fields/frequency/value');
 
        $frequencyDaily = Mage_Adminhtml_Model_System_Config_Source_Cron_Frequency::CRON_DAILY;
        $frequencyWeekly = Mage_Adminhtml_Model_System_Config_Source_Cron_Frequency::CRON_WEEKLY;
        $frequencyMonthly = Mage_Adminhtml_Model_System_Config_Source_Cron_Frequency::CRON_MONTHLY;
 
        $cronDayOfWeek = date('N');
 
        $cronExprArray = array(
            intval($time[1]),
            intval($time[0]),
            ($frequency == $frequencyMonthly) ? '1' : '*',
            '*',
            ($frequency == $frequencyWeekly) ? '1' : '*',
        );
 
        $cronExprString = join(' ', $cronExprArray);
 
        try {
            Mage::getModel('core/config_data')
                ->load(self::CRON_STRING_PATH, 'path')
                ->setValue($cronExprString)
                ->setPath(self::CRON_STRING_PATH)
                ->save();
            Mage::getModel('core/config_data')
                ->load(self::CRON_MODEL_PATH, 'path')
                ->setValue((string) Mage::getConfig()->getNode(self::CRON_MODEL_PATH))
                ->setPath(self::CRON_MODEL_PATH)
                ->save();
        } catch (Exception $e) {
            throw new Exception(Mage::helper('cron')->__('Unable to save Cron expression'));
        }
    }
 
}

El siguiente paso es indicarle al valor de configuración que para manejar los datos, aplique éste modelo.

Para esto, vamos a abrir el archivo /etc/system.xml de nuestro módulo y vamos a agregar un nuevo parámetro dentro del nodo fields que será el de la configuración específica del cron job.

 translate="label">
    >Start Time>
    >time>
    >1>
    >1>
    >0>
    >0>
>
 translate="label">
    >Frequency>
    >select>
    >adminhtml/system_config_source_cron_frequency>
    >modulo/config_cron_proceso>
    >2>
    >1>
    >0>
    >0>
>

Ahora guardamos y accedemos a la configuración.

El resultado debería ser similar (el mismo en realidad) a lo que vemos a continuación.

Ahora ya podemos configurar nuestro cron job desde el backend sin tocar los archivos de la plataforma.

A lo mejor te interese leer

Crear un cron job en Magento

Damián — Tue, 21 Sep 2010 02:00:26 +0000

Muchas veces vamos a necesitar procesos que se ejecuten sin importar si del otro lado de la pantalla hay algún usuario realizando alguna acción.

Por lo general éste tipo de tareas tienen que ver más con procesos administrativos que con la experiencia de compra en si misma.

Una de las funcionalidades de Magento es el cron, que no es más que una extensión del cron del sistema operativo. La pequeña diferencia sería que desde el sistema operativo ejecutamos un único archivo de la plataforma y ésta, según configuraciones, se encargará de correr los procesos que correspondan.

Un cron job para Magento es, básicamente, un método de un modelo que se encargará de realizar una acción.

Para lograr el nuestro, lo primero sería crear la clase y el método que más tarde invocaremos. Un ejemplo podría ser el siguiente.

class Dc_Modulo_Model_Cron {
 
    public function runMyCronJob() {
 
        //Acciones a realizar
 
    }
 
}

De más está decir que lo que haga el método quedará librado a la necesidad de cada uno. No hace al ejemplo definir algún proceso.

Para lograr que el cron job sea insertado dentro de la lista de ejecución tenemos que agregar algunas líneas a la configuración de nuestro módulo.

>
    ...
    >
        >
            >
                >
                    >modulo/cron::runMyCronJob>
                >
                >
                    >45 23 * * *>
                >
            >
        >
    >
>

Los datos que acabamos de agregar indican lo siguiente.

es el nombre del cron job. El nombre debe ser único. Dentro de le indicamos el model a ejecutar. El tag es el que, utilizando el mismo tipo de expresión que se aplica para el cron del sistema operativo, va a indicar la hora de ejecución.

De ésta forma, tendremos nuestro proceso corriendo cada vez que se cumpla la condición de la hora.

Para más información sobre cómo configurar la ejecución de los cron jobs y para conocer cuáles procesos ya vienen con Magento, pueden darle una leída al siguiente artículo en la wiki sobre el cron.

A lo mejor te interese leer

Cómo crear un renderer para las grillas en Magento

Damián — Mon, 20 Sep 2010 02:00:09 +0000

Si bien tanto para los formularios como para las grilla Magento nos provee de una serie de tipos listos para usar, en algunas oportunidades nos hará falta alguna nueva funcionalidad.

En el caso de las grillas, es bastante sencillo agregar un nuevo tipo de columna.

Normalmente, cuando nuestro formulario permite subir archivos, el resultado en la grilla sería el siguiente.

La columna filename se muestra como texto, pero en realidad es una referencia a un archivo que nos gustaría poder ver como imagen.

Para lograr éste cambio vamos a crear nuestro propio renderer para esa columna. El primer paso es crear el renderer, que es una clase de tipo Block.

class Dc_Modulo_Block_Adminhtml_Renderer_Image extends Mage_Adminhtml_Block_Widget_Grid_Column_Renderer_Abstract {
 
    //Este es el método que será devuelto a la grilla.
    public function render(Varien_Object $row) {
        return ($this->_getFilename($row));
    }
 
    //Separando un poco el código, en éste método aplicamos las transformaciones que necesitemos para el valor.    
    protected function _getFilename(Varien_Object $row) {
        $image = $row->filename != '' ? ' . Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_MEDIA) . $row->filename . '" alt="" />' : '';
        return $image;
    }
 
}

Una vez que tenemos definido el renderer, vamos a cambiar algunos valores en la definición de la columna de nuestra grilla.

$this->addColumn('filename', array(
    'header'    => Mage::helper('modulo')->__('Filename'),
    'align'     => 'center',
    'width'     => '300px',
    'filter'    => false,
    'sortable'  => false,
    'renderer'  => 'modulo/adminhtml_renderer_image',
));

Ahora sólo debemos volver a mirar nuestra grilla y el resultado debería ser similar a éste.

De acá en más, la posibilidad de presentar datos en las grillas tendría que resultarnos algo más sencillo.

A lo mejor te interese leer

Dropdowns en los formularios de backend de Magento

Damián — Mon, 13 Sep 2010 04:17:59 +0000

Uno de los ejemplos que el creador de módulos de Magento no incluye para el caso de los formularios del backend, es el del uso de dropdowns que deben ser llenados con valores de algún modelo que referencia a una tabla.

Por defecto, nos encontramos con esto.

Para lograrlo, el código que se utiliza en la composición del formulario es el siguiente.

$fieldset->addField('status', 'select', array(
    'label'     => Mage::helper('news')->__('Status'),
    'required'  => true,
    'name'      => 'status',
    'values'    => array(
        array(
            'value'     => 1,
            'label'     => Mage::helper('news')->__('Enabled'),
        ),
        array(
            'value'     => 2,
            'label'     => Mage::helper('news')->__('Disabled'),
        ),
    ),
));

Uno de los problemas de ésta modalidad, es que luego nuestro modelo deberá responder por esos mismos id’s para poder mostrar, “hacia afuera”, los valores como corresponden. Queda claro que dependiendo de la cantidad de opciones que vayan a utilizarse para llenar el dropdown, esto podría convertirse en una situación difícil de mantener.

Supongamos que estamos haciendo un módulo que se compone por más de un formulario, y donde uno de éstos genera valores que serán usado por un segundo. A manera de ejemplo, podríamos pensar en un sencillo módulo de noticias, en donde en el primero de los formularios cargaríamos una categoría y luego en el segundo seleccionaríamos en un dropdown la categoría.

¿Cómo hacer entonces para que los que carguemos como categorías sea utilizable por el segundo formulario sin tener que estar editándolo?.

La solución no dista de ser sencilla. Para empezar, vamos a agregar un método al modelo que gestiona (siguiendo el ejemplo) las categorías de nuestro módulo de noticias. En particular vamos a tomar la clase collection.

Supongamos que el módulo se llamara Dc_News. Vamos a buscar el archivo Dc_News_Model_Mysql4_Categories_Collection y le agregamos el siguiente código.

public function toOptionArray(){
    return $this->_toOptionArray('campo_id', 'campo_texto_a_mostrar');
}

Ahora volvemos a nuestro formulario y vamos a modificar un poco la definición del campo que estamos rendereando como dropdown.

Previo a la definición vamos a agregar ésta línea.

$_categories = Mage::getModel('news/categories')->getCollection()->toOptionArray();

Luego, en la especificación del campo, en lugar de agregar el array de valores utilizamos la variable que definimos previamente como el value de éste campo.

$fieldset->addField('category', 'select', array(
    'label'     => Mage::helper('news')->__('Category'),
    'required'  => true,
    'name'      => 'category',
    'values'    => $_categories,
));

Una vez hecho esto, y suponiendo que ya cargamos algunos valores, el campo en nuestro formulario debiera de mostrar algo como esto.

Con ésto tenemos las dos variantes para utilizar dropdowns en nuestros módulos de Magento.

A lo mejor te interese leer

Url friendly en CodeIgniter

Damián — Mon, 09 Aug 2010 13:00:45 +0000

CodeIgniter nos permite la utilización de urls amistosas (si, la traducción suena bastante fea).

Dado que por defecto ésto no funciona, tenemos que hacer algunos pequeños ajustes.

Lo primero será crear un archivo .htaccess con lo siguiente.

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

A partir de ahora, en lugar de usar:

http://www.dominio.com.ar/index.php/controlador/accion/

Vamos a poder usar:

http://www.dominio.com.ar/controlador/accion/

Para que la impresión de urls resulte correcta, es necesario hacer un ajuste en el archivo de configuración. Esto aplica en particular si vamos a usar la función site_url del helper Url.

Para evitar que al llamar a la función nos devuelva http://www.dominio.com.ar/index.php, vamos a cambiar la línea 23 de /system/application/config/config.php, y vamos a dejar el valor de la key index_page en blanco.

La configuración debería quedar de ésta forma:

$config['index_page'] = "";

Con estos pequeños ajustes ya deberíamos estar aplicando urls semánticas sin problemas.