Certificación Magento-Conceptos Básicos: Fundamentos-Preguntas y Respuestas

Preguntas y respuestas:

PREGUNTA 1: ¿Cuáles son algunos de los patrones de diseño implementados en el Framework?, y ¿cómo se diferencian de la implementación básica de este patrón?

Magento está basado en Zend Framework , el cual utiliza muchos patrones de diseño que directamente son heredados por Magento; entre ellos:

  • Factory: Este patrón delega la creación de los objetos sobre un objeto llamado Factory. En Magento tendriamos este patrón en [PHP]$product = Mage::getModel(‘catalog/product’);[/PHP]
  • Singleton: Asegura que la clase solo tiene una instancia de ella y asegura un punto de acceso a ella. En Magento podemos ver su uso en el archivo Mage.php alojado en el directorio app.
  1. public static function getSingleton($modelClass='', array $argumenxrts=array())
  2. {
  3. $registryKey = '_singleton/'.$modelClass;
  4. if (!self::registry($registryKey)) {
  5. self::register($registryKey, self::getModel($modelClass, $arguments));
  6. }
  7. return self::registry($registryKey);
  8. }

y un ejemplo a la hora de instanciar un objeto:

  1. $category = Mage::getSingleton('catalog/session');
  • Registry: El patrón básico suele ser una clase estática, así se podrá acceder a sus métodos sin la necesidad de instanciar la clase. Unos de los métodos principales que debe contener esta clase serán add()->para almacenar valores a una variable  y el método get() para recuperar el valor de una variable. En Magento estos métodos equivaldrían a  Mage::register() el cual realiza la misma función que el add(), y Mage::registry() que equivale a get(). Adicionalmente también tenemos el método Mage::unregister() que resetearía la variable pasada como parámetro. Estos métodos los encontraremos en app/Mage.php
  • Observer: El patrón Observador (en inglés: Observer) también conocido como “spider” define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el observador se encarga de notificar este cambio a todos los otros dependientes. El objetivo de este patrón es desacoplar la clase de los objetos clientes, aumentando la modularidad del lenguaje, así como evitar bucles de actualización. Un ejemplo de como se lanza el evento sería el siguiente:
  1. Mage::dispatchEvent('custom_event', array('object'=>$this));

y su definicion la  podremos encontrar en Mage.php:

  1. public static function dispatchEvent($name, array $data = array())    {
  2. Varien_Profiler::start('DISPATCH EVENT:'.$name);
  3. $result = self::app()->dispatchEvent($name, $data);
  4. #$result = self::registry('events')->dispatch($name, $data);
  5. Varien_Profiler::stop('DISPATCH EVENT:'.$name);
  6. return $result;
  7. }

y en el archivo config.xml tendriamos la definición del observer para el evento que queramos:

  1. <observer>Class_Name/methodName</observer>
  • Object Pool: Este patrón consiste en evitar el alto coste de adquisición y liberación de recursos reciclando objetos usados durante un corto periodo de tiempo. Suele ser usado en reutilización de conexiones o en patrones de lanzamientos de hilos. Un ejemplo de uso podría ser el siguiente:
  1. $id = Mage::objects()->save($object);
  2.  
  3. $object = Mage::objects($id);
  • Iterator: Provee una manera de acceder a los elementos agregados a un objeto. En Magento este patrón se representa mediante los Collection.

  1. Mage::getModel('catalog/product')->getCollection();

Nota: una característica heredada de Zend Framework es que todo tipo de objeto Model dispone de un Collection asociado para poder recorrer los datos.

  • View Helper: Este patrón muestra una separación adicional con la capa de Vista. Las plantillas de visualización utilizarían los Helper para los acceso a los datos. En Magento podemos declarar un helper de la siguiente manera:
  1. public static function helper($name)
  2. {
  3. $registryKey = '_helper/' . $name;
  4. if (!self::registry($registryKey)) {
  5. $helperClass = self::getConfig()->getHelperClassName($name);
  6. self::register($registryKey, new $helperClass);
  7. }
  8. return self::registry($registryKey);
  9. }

Nota: Dentro de una extensión podremos encontrar dicho patrón en la carpeta Helper dentro de nuestros módulos. Además siempre que hagamos una declaración como la que hemos descrito arriba, por defecto buscaría un helper llamado Data.php.

Dicho helper llama a self::getConfig()->getHelperClassName(\$name); función que podremos encontrar en app/code/core/Mage/Core/Model/Config.php:

  1. public function getHelperClassName($helperName)    {
  2. if (strpos($helperName, '/') === false)
  3. {
  4. $helperName .= '/data';
  5. }
  6. return $this->getGroupedClassName('helper', $helperName);
  7. }
  • Lazy Loading: Este patrón de diseño defiende que no se cree el objeto hasta que sea estrictamente necesario. En Magento tenemos este patrón cuando se necesita realizar llamadas sobre la BBDD. Cuando estás escribiendo una consulta SQL o cuando estás utilizando el sistema ORM, las llamadas SQL son creadas junto en la inicialización del objeto:
  1. $model = new Customer();
  2. //SQL Calls being made to Populate the Object echo 'Done';
  3.  
  4. //execution continues

Magento no trabaja de esta manera, en su lugar usa el patrón mencionado anteriormente, lo que significaría que la llamada al SQL no se realizaría hasta que el programa-cliente necesite el acceso a datos. Veamos el siguiente ejemplo:

  1. $collection_of_products = Mage::getModel('catalog/product')->getCollection();
  2. /*Aquí todavía no hemos realizado el acceso a los datos.*/
  3. $collection_of_products->addAttributeToSelect('meta_title');
  4. /*todavía no ha accedido a los datos, con lo cual podemos añadir todos los atributos necesarios*/

El Query no se realizará hasta que realices un acceso a un item del collection
PREGUNTA 2: ¿Como se construyen las clases en Magento?
El proceso de generación de clases es un sistema independiente,  en el cual está recogido en  la clase Mage_Core_Model_Config. La generación de las clases se realiza mediante un mezclado de archivos .xml.
Magento recorrerá estos xml e irá realizando un mezclado de elementos, para terminar con un archivo xml master con la definición de todas las clases.
Por Ejemplo:
Definición de config de un Módulo A:

  1. <config>
  2.  
  3. <uno></uno>
  4.  
  5. <dos>moduloA</dos>
  6.  
  7. <tres></tres>
  8.  
  9. </config>

Después se realiza la definición de elementos del Módulo B con el sigiente archivo config.xml:

  1. <config>
  2.  
  3. <dos>moduloB</dos>
  4.  
  5. </config>

El resultado del mezclado finalmente quedaría de la siguiente manera:

  1. <config>
  2.  
  3. <uno></uno>
  4.  
  5. <dos>moduloB</dos>
  6.  
  7. <tres></tres>
  8.  
  9. </config>

Nota: En el proceso de mezclado del conjunto de xml siempre prevalecerá el que se ejecutó posteriormente, como vimos en el ejemplo anterior el Modulo B reescribiría el elemento <uno>Modulo B<\uno>, previamente definido por el Modulo A.

5 comentarios sobre “Certificación Magento-Conceptos Básicos: Fundamentos-Preguntas y Respuestas”

  1. Hola que tal, muy buenos tus post, solo para comentarte que los códigos se ven mal ya que muestra las etiquetas HTML.

    de antemano Gracias!

  2. Hola, ya instalamos y le dimos los permisos 755 a todos los ficheros y carpetas pero no está tomando todos los estilos ni están visibles las carpetas etc, alguna idea de como solucionarlo? Gracias

    1. ¿Que te dice firebug? has mirado de donde esta intentando recuperar los recursos para descartar que los esté intentando recuperar de una dirección que no sea la correcta.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *