Certificación Magento- Estructura y localización de ficheros en una extensión

Introducción:

Una vez introducidos en previas entradas los conceptos de patrones de diseño, estamos preparados para adentrarnos en la estructura de un módulo y la distribución de todos los contenidos que lo rodean.

Estructura de un Módulo:

El contenido de un Módulo en Magento se va a distribuir en una serie de directorios, cada uno destinado a cubrir una determinada funcionalidad. Primero se explicará toda la estructura de carpetas, y después se profundizará en el contenido de cada una de ellas.

  • Block
  • Controller
  • controllers
  • data
  • etc
  • Helper
  • Model
  • sql

Aquí disponemos de un conjunto de directorios, unos de los cuales son mas usados y otros menos usados. Algunos de estos directorios son algo atípicos ya que es necesario adentrarse en los módulos del core para poder visualizarlos, como por ejemplo el Controller y data.

  • Block: Mageto utiliza Bloques para cubrir el apartado de la vista, más concretamente es la fusión de un archivo php con un template .phtml que veremos mas adelante.  El archivo PHP contiene una clase que siempre hereda de Mage_Core_Block_Abstract, ya sea directamente o mediante algunos pasos intermedios.
  • Controller: Magento ha utilizado en su desarrollo un método típico de C, el cual dice que “ante la duda, realizar una clase nueva”. Por eso disponemos de una multitud realizando prácticamente funcionalidades muy similares. Dicho esto, cabe destacar que en la carpeta Controller dispondremos de controladores más generales que recogen funcionalidades comunes que podremos reutilizar en los controladores disponibles en el directorio que viene a continuación.
  • controllers: Como se describió en entradas anteriores, Magento utiliza el patrón de diseño de MVC, y en este directorio encontraremos los controladores que se ocupan de la lógica de negocio. En Magento esta responsabilidad recae mas sobre el Model, aquí es una diferencia de implementación con el patrón original.
  • data: esta es una carpeta curiosa, la cual creo recordar que ha sido introducida en la versión 1.6 y posteriores de Magento. En esta carpeta, tendremos los scripts que prepararían nuestro Magento con una serie de datos necesarios para el funcionamiento de una extenión, como por ejemplo la creación de un Bloque de CMS. El funcionamiento es exactamente igual que la carpeta sql. También disponemos de la lógica del control de versiones de la extensión para mantener la escalabilidad de nuestros módulos.
  • etc: Magento utiliza un sistema de configuración basado en archivos .xml, digamos que en esta carpeta vamos a tener todos estos ficheros que componen la configuración de nuestra instalación.
  • Helper: Como se vió en una entrada anterior, Helper es un patrón de diseño el cual es utilizado para darnos una última conexión entre los datos (Model) y la vista (View).
  • Model: es una de las partes importantes de nuestros desarrollos. En este directorio encontraremos la parte dedicada a la interacción con la BBDD.
  • sql: aquí encontraremos los script de mysql que nos permitirán dotar de parámetros de configuración a nuestros módulos. Contiene todo lo referente a necesidades para la puesta en marcha de nuestro Módulo, como por ejemplo: dar de alta un nuevo atributo para el  producto, dar de alta una nueva sección de configuración en nuestras categorías, etc.

En este punto, realizamos una pausa para destacar un pequeño detalle. Podemos apreciar que algunas de las carpetas del módulo están escritas comenzando por minúscula y otras no. Podríamos entender que las que están escritas en minúscula son aquellas carpetas en las que va a entrar el sistema para realizar cualquier operación.

  • etc: entra para leer el fichero .xml de configuración.
  • data: entra para ejecutar los ficheros .sql
  • sql: idem a data.
  • controllers: los controllers forman parte de los elementos que no están bajo el autoload, así que es otro lugar donde entra nuestro sistema para ejecutar dichos action asociados.

Lo normal es que nuestra aplicación esté bajo un servidor linux, el cual es sensible a mayúsculas y minúsculas, así que para evitar cualquier error se decidió que comenzaran por minúsculas.

Diferentes Code Pool de Magento:

Disponemos de una serie de code Pool para diferenciar el autor de cada uno de los módulos.

  • core: en este code Pool estarán todos los módulos desarrollados por Magento Inc. y que en cada una de las versiones van modificando/añadiendo para añadir funcionalidades, o corregir errores por ejemplo. Bajo ningún concepto se tiene que modificar cualquier módulo disponible en dicho directorio dado que las modificaciónes pueden ser traumáticas. Ejemplo: ante una actualización perderías todo lo desarrollado, como tampoco encontraríamos las modificaciones realizadas de una manera trivial.
  • community: aquí vamos a encontrar desarrollos que han sido aceptados por la comunidad de Magento, ya sean realizados por ellos o por terceros, pasando en este caso una serie de requisitos.
  • local: destinado a los módulos desarrollados por terceros y módulos propios. Aquí es donde tenemos que introducir nuestros desarrollos.

Estos directorios los podremos encontrar en app/code/[community]|[core]|[local]

Contenido estático de un módulo:

A parte de lo comentado anteriormente, un módulo reparte su contenido estático por diversos lugares de nuestra aplicación. A continuación veremos cada uno de dichos directorios.

  • layout (app/design/cascade/layout): Magento dispone de un sistema de templating apartado del desarrollo. Con esto lo que pretenden es poder dotar de la creación de clases (bloques) sin la necesidad de tener fundamentos de PHP. Este sistema, al igual que el sistema de configuración, esta desarrollado con archivos .xml .
  • template (app/design/cascade/template): directorio en el que se encontrarán los archivos .phtml mencionados anteriormente y que tienen una íntima relación con el php. El contenido de este archivo será HTML + PHP.
  • skin (skin/cascade): reservado a contenido estático de nuestra extensión, posibles ficheros que permanecerán en este directorio serían: css, js, images, etc.
  • js: En caso de que nuestra extensión requiera de alguna librería del tipo js, aquí es donde se debería de alojar. Si queremos un pequeño truco para para diferenciar cuándo introducir un js en este directorio o en skin, podemos pensar que aquí iría si este js pudiera valerse por sí solo, lo que significaría que podría cogerla de aquí y utilizarla en otro proyecto. Ejemplos: jQuery, validator.js, etc.
  • lib: Puede darse el caso en que nuestra extensión requiera alguna librería php, así que, aquí sería donde la introduciriamos. Ejemplo: barcode, etc.

Hacemos otra parada en el camino, únicamente para mencionar otro de los temas que la mayoría no termina de tener claro y que es muy importante de entender. En la explicación de los directorios anteriores hemos podido apreciar que he redactado la palabra cascade, refiriéndome al “sistema de cascada de Magento”.

Magento dispone de un sistema de casacada en la busqueda del contenido estático según el cual buscaría un recurso en estructuras de nivel superior/mas genérico. Esto será visto en profundidad con algún ejemplo en posteriores entradas.

 

3 comentarios sobre “Certificación Magento- Estructura y localización de ficheros en una extensión”

  1. Buen Resumen David. Breve y al grano.
    Tengo mis dudas sobre la frase “se ocupan de la lógica de negocio de nuestro Magento.” en los controllers. La lógica yo la veo más en los Model ¿no?.

    En la descripción de los Helper; creía que eran para poder alojar funciones “miscelaneas” que no se encuadren con la lógica de negocio. lo que indicas es interesante. Volveré a repasarlo para tenerlo más claro.

  2. Buenas Miguel, respecto a la primera cuestión llevas toda la razón, esto es un tema que comenté en la primera entrada de la certificación donde explicaba que Magento rompe un poco el patrón de diseño MVC, delegando la lógica de negocio mas en la parte de los Model. Gracias por la anotación, modificaré la entrada posteriormente.

    Respecto a los Helper, comentarte que es uno de los elementos que mas me cuesta encasillar en algún sitio. Si nos fijamos en el siguiente diagrama Diagrama Secuencia podemos ver que el Helper lo situa en la parte de la Vista y que realiza conexión entre los Modelos y Controllers.

    De todas maneras creo que es usado con diversas funcionalidades, echale un vistacillo a este enlace Helper Patrón de diseño

    Resumiendo, bajo mi punto de vista lo usaría para realizar operaciones con los Modelos que fueran necesarios en las Vistas, Reutilizar lógica utilizada en la vista, añadir un nivel mas en nuestro sistema, operaciones misceláneas, etc.

Deja un comentario

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