Siguiendo con la idea de armar módulos que podamos reutilizar, vamos a ver cómo agregar archivos javascript pero sólo si hemos configurado desde el backend su inclusión.

Si antes aplicamos el método addCss, en ésta oportunidad tenemos dos formas de llamar a un archivo js.

El código a usar, si nuestro archivo js debe incluirse cada vez que se instancie nuestro módulo, sería el siguiente si es que el archivo se encuentra en la carpeta /skin.

<layout version="0.1.0">
 
    ...
 
    <default>
        <reference name="head">
            <action method="addItem"><type>skin_js</type><name>js/archivo.js</name></action>
        </reference>
    </default>
 
    ...
 
</layout>

Y de ésta otra forma lo hacemos si es que estamos agregando una librería ubicada en /js.

<layout version="0.1.0">
 
    ...
 
    <default>
        <reference name="head">
            <action method="addJs"><script>carpeta/archivo.js</script></action>
        </reference>
    </default>
 
    ...
 
</layout>

Supongamos ahora que armamos un módulo que requiere de una librería (para mi ejemplo y por preferencia, pensemos que es jQuery), pero que siendo la nuestra una extensión, podría pasarnos que al agregarla a un proyecto, jQuery ya se esté usando.

La solución de artesano sería editar el código de nuestro módulo y quitar la llamada a ese javascript (algo que puede llegar a ser realmente tedioso si éste módulo lo reutilizáramos todo el tiempo).

Para resolver éste escenario, vamos a hacer uso de uno de los condicionales que podemos aplicar en el layout. En éste caso será el turno de ifconfig, que se encarga de validarse contra una key de configuración que le indiquemos.

Siguiendo con la idea de agregar una librería que podría o no estar presente, el código quedaría de la siguiente forma.

<layout version="0.1.0">
 
    ...
 
    <default>
        <reference name="head">
            <action method="addJs" ifconfig="javascript/jquery/custom"><script>jquery/jquery.js</script></action>
        </reference>
    </default>
 
    ...
 
</layout>

Para que esa key de configuración pueda ser editada, le agregamos a nuestro módulo la opción de configuración. En este caso, podría verse de la siguiente manera.

Desde ahora, si cuando agregamos el módulo la librería que necesitamos no está siendo usada, activamos su uso mediante la configuración.

Si nos toca agregarla en un proyecto en el cual, por ejemplo, la librería ya es invocada desde el page.xml, no tendremos necesidad de modificar ningún archivo para evitar la doble instancia de la misma librería.

A lo mejor te interese leer

• Mejorando el SEO de nuestros módulos en Magento
• Agregar validaciones javascript en Magento de forma no obstrusiva
• Configuraciones dependientes en Magento
• Cómo agregar atributos a una categoría en Magento
• Cómo modificar valores de configuración vía código en Magento

Básicamente tenemos dos formas (algunas más en realidad si queremos hacer las cosas poco prolijas).

La primera y más extendida, sería tomar page.xml de nuestro layout y repetir, por ejemplo la siguiente línea.

<action method="addCss"><stylesheet>css/mi_css.css</stylesheet></action>

Le cambiamos el nombre del archivo (que deberá estar ubicado en el path correcto) y con eso vamos a tener nuestro archivo css listo para ser leído.

La segunda forma de hacerlo, que nos sirve para nuestras extensiones, es hacer esto mismo pero desde la definición de layout del módulo.

Esto nos permitirá que sólo en los casos en los que el módulo se instancie, o incluso sólo en una sección, se agregue nuestro archivo css.

Dado que el archivo css ya lo tenemos ubicado dentro de las carpeta de skin correspondiente, vamos a agregar la definición a nuestro módulo.

Vamos a suponer que el módulo se llama Noticias. Normalmente, encontraríamos dentro de la carpeta de layout del frontend un archivo noticias.xml.

Dentro de ese archivo tenemos que agregar las siguientes líneas.

<?xml version="1.0"?>
<layout version="0.1.0">
 
    ...
 
    <default>
        <reference name="head">
            <action method="addCss">
                <name>noticias.css</name>
            </action>
        </reference>
    </default>
 
    ...
 
</layout>

De ésta forma le decimos que tome el bloque “head” (que se encuentra definido en page.xml) y agregue un archivo css. Luego se le pasa el path al archivo que puede ser cualquiera dentro de la carpeta de skin the nuestro theme.

A lo mejor te interese leer

• Incluir archivos JS por layout según configuración en Magento
• Sobreescribir templates en Magento desde el layout
• Mejorando el SEO de nuestros módulos en Magento
• Agregar validaciones javascript en Magento de forma no obstrusiva
• Configuraciones dependientes en Magento

Normalmente, cuando trabajamos con un skin desde el comienzo, más allá de las líneas de diseño que puedan existir, tenemos bastante libertad de elección en la forma en que se va estructurar ese theme.

Ahora bien, cambia radicalmente el escenario cuando nos dedicamos a crear extensiones o cuando ciertas customizaciones que hayamos desarrollado se tornan parte de la batería de módulos y ajustes que usamos en cada proyecto.

Si para cada caso debiéramos estar modificando los archivos phtml, los xml, el css… bueno, sería bastante molesto y estaríamos dejando de tener código reutilizable.

A través de las definiciones de layout podemos aplicar cambios al momento de renderear el template sin hacer modificaciones a los archivos que ya se estén usando. En realidad, hay unas cuantas cosas que pueden hacerse, pero dada la cantidad de funciones con las que contamos para el manejo del layout, sólo me voy a centrar en el reemplazo de llamadas a los phtml.

Como ejemplo, vamos a tomar el selector de moneda. Vamos a suponer también que tenemos definido el update de layout en el módulo.

Ahora bien, el selector de moneda (suponiendo que nuestra tienda posee más de una y lo tenemos cofigurado) se muestra en varias secciones. En el archivo /app/design/frontend/base/default/layout/directory.xml tenemos todas las indicaciones.

Para el ejemplo, vamos a usar la llamada que se utiliza en la vista de categoría.

<?xml version="1.0"?>
<layout version="0.1.0">
 
    ...
 
    <catalog_category_default>
        <reference name="left">
            <block type="directory/currency" name="currency" before="catalog.leftnav" template="directory/currency.phtml"/>
        </reference>
    </catalog_category_default>
 
    ...
 
</layout>

Podemos ver que al bloque referenciado como “currency” se le asigna el template “directory/currency.phtml”.

Para hacer nuestro reemplazo sin alterar archivo alguno, tenemos que hacer uso del método setTemplate, que se encargará de reasignar un nuevo phtml al mismo bloque. Supongamos que la definición de layout de nuestro módulo estuviera en un archivo llamado currency.xml, el mismo debería tener la siguiente definición para aplicar el cambio.

<?xml version="1.0"?>
<layout version="0.1.0">
 
    ...
 
    <catalog_category_default>
        <reference name="currency">
            <action method="setTemplate"><template>path/a/mi/nuevo/currency.phtml</template></action>
        </reference>
    </catalog_category_default>
 
    ...
 
</layout>

Con ésta nueva definición, lo que estamos haciendo es indicar que en la vista de categoría, se busque el bloque llamado “currency” y se cambie el template por este que hemos definido.

De ésta forma, estamos haciendo una sobreescritura no intrusiva.

A lo mejor te interese leer

• Incluir archivos JS por layout según configuración en Magento
• Cómo agregar un archivo CSS por layout en Magento
• Mejorando el SEO de nuestros módulos en Magento
• Agregar validaciones javascript en Magento de forma no obstrusiva
• Configuraciones dependientes en Magento

Su uso es absolutamente sencillo.

Al igual que cuando invocamos {{skin url=”"}} para imprimir algún contenido de un skin dado, la variable media utiliza el mismo parámetro.

<img src="{{media url="imagen.jpg"}}" alt="Magento" border="0"/></a>

Esto hará que se busque la imagen dentro de la carpeta media. Si usáramos subcarpetas, deberemos escribir el path partiendo siempre desde dicha carpeta.

Si bien puede parecer una pavada la inclusión del template, su uso puede entenderse en el caso de campañas de promoción, en las cuales podríamos utilizar (es sólo un ejemplo para graficar) el mismo banner que tenemos en la home de la tienda, en el cuerpo del mail.

A lo mejor te interese leer

• Eligiendo el Skin para las plantillas de Email en Magento
• Mostrar phtmls y bloques usados en el skin de backend de Magento
• Mostrar los bloques html en el frontend de Magento
• Configurar la cantidad de registros por defecto en una grilla
• Incluir archivos JS por layout según configuración en Magento

Una de sus contras, es que al momento de necesitar una mínima personalización, uno puede terminar sintiéndose perseguido por una multitud de líneas de código corriendo en círculos.

Hoy vamos a ver un pequeño truco, detalle, …… (complete la línea punteada con la palabra que mejor le resulte); que sirve para indicarle a la plantilla, de qué skin tomará las imagenes que se mostrarán en el caso de las plantillas html.

Si ya les tocó tener que personalizar esas plantillas, es probable que hayan visto dentro del código que imprime el logotipo, una línea parecida a la siguiente.

<td valign="top"><a href="{{store url=""}}"><img src="{{skin url="images/logo_email.gif" _area='frontend'}}" alt="Magento"  style="margin-bottom:10px;" border="0"/></a></td>

Un repaso rápido de las variables usadas:

• {{store url=”"}} es el base_url de la tienda. Por ejemplo: http://www.mitienda.com.ar/
• {{skin url=”…”}} transforma el source de la imagen a http://www.mitienda.com.ar/skin/frontend/default/default/ y le concatena images/logo_email.gif. Nos quedaría la siguiente url: http://www.mitienda.com.ar/skin/frontend/default/default/images/logo_email.gif.
• {{skin url}} aplica una directiva: _area=’frontend’. Como vimos en el punto anterior, la imagen es tomada desde …/skin/frontend/. Si el valor de _area lo cambiamos por _area=’adminhtml’, el template buscará la imagen dentro del contenido del skin default/default del backend.

Hasta acá tenemos lo que a simple vista se ve y más o menos podíamos suponer.

Para la variable {{skin url}} tenemos dos directivas adicionales, no documentadas, que nos dan un poco más de flexibilidad. Un ejemplo podría ser:

<img src="{{skin url="images/logo_email.gif" _area='frontend' _package='paquete' _theme='tema'}}" alt="Magento"  style="margin-bottom:10px;" border="0"/>

Las dos “nuevas” directivas funcionan de la siguiente manera.

• _package=’paquete’ determina de que paquete del skin se está hablando. Recuerden que los skins pueden estar conformados por múltiples paquetes con múltiples temas cada uno. Si usáramos como skin default/blue, default sería el paquete y blue el tema.
• _theme=’tema’ hace exactamente lo mismo pero, obviedad mediante, a nivel tema.

De ésta forma, podríamos estar usando un skin determinado para nuestra tienda, y podríamos usar imagenes de otro skin en nuestros templates. En realidad, podríamos hacer tantas combinaciones y configuraciones como complicaciones o requerimientos nos lleguen.

A lo mejor te interese leer

• Variable media en las plantillas de email de Magento
• Mostrar phtmls y bloques usados en el skin de backend de Magento
• Mostrar los bloques html en el frontend de Magento
• Configurar la cantidad de registros por defecto en una grilla
• Incluir archivos JS por layout según configuración en Magento