gustavo

Templates have always been one of Joomla!’s strengths. The vast number of free and commercial templates designed for Joomla! 1.0 are the best proof of the success of the Joomla! template system. After beta release we received allot of questions on the forums about the template system changes in Joomla! 1.5 beta.

While the beta is only intended for feedback and testing purposes we realize designers need more information to truly test the template changes. On the forums designers have been telling us we can’t expect them to go and read the code to understand the new system. They are absolutely right !

In the coming week I will be blogging about the different changes we made. I’ll try to answer the many questions people have been posting on the forums. I will also try to explain why certain changes have been made. The information will be a bit technical from time to time but I believe it’s important you not only understand the ‘how’ but also the ‘why’.

Time to dive in …
Backwards compatibility with 1.0

Before we dive into the real stuff let’s talk about backwards compatibility. The new system has been designed to be fully backwards compatible with Joomla! 1.0. If u are installing a Joomla! 1.0 template make sure u turn on the ‘legacy mode’ in the server tab in global configuration. This layer loads all the 1.0 functionality that has been deprecated in 1.5.

Beware of the Menu Modules parameter settings compared to the default 1.0.x settings. In this first beta, they are displayed as list and that breaks menus in solarflare for example. Change to Vertical or Horizontal when needed. This could change in beta 2.

A _menu suffix has been added per default to the menu modules parameters. This will be taken off to maintain backward compatibility in the next beta release.
What is new in 1.5 ?

The changes to the template system in Joomla! 1.5 can be divided into two categories. First of all there are changes to the way things where done in Joomla! 1.0, for example the new way modules are loaded, and second there are also a bunch of extra features, like template parameters, … a quick overview :
1. Changes to the old ways

mosCountMoules

The mosCountModules function has been replaced by the $this->countModules function and support for conditions has been added. This allows designers to easily count the total number of modules in multiple template positions in just one line of code, for example $this->countModules(’user1 + user2′); which will return the total number of modules in position user1 and user2.

Including output generated by the core

In Joomla! 1.0 u could use different functions to include the output generated by the core. These functions have all been replaced by the < jdoc :include ... /> element. For example modules in a certain position can be included using < jdoc :include type="modules" name="left" />

Loading the editor

In Joomla! 1.0 u needed to load the editor yourself in your templates. This is not needed anymore. When the system renders the head of your template it will decide if the editor needs to be included or not.
2. New features

Template parameters

Template parameters can be used to let administrators control the template structure. They work much in the same way as module parameters. A template designer can define extra template settings in the templates xml file and the site administrator can adjust them in the template manager. For example, administrators could switch color schemes, choose between a 2 or 3 column layout … or set the minimum width of the template.

Template Overrides

Templates can override the default output of the core, for example u could easily override the way an article is rendered and change the table output to divs. Or u can change a class or id to your liking. Pagination rendering and module styles can also be extended.

Support for multiple css files

The template manager supports multiple css files so u don’t need to put all your css into one file. We also changed the naming of the master css file to template.css instead of template_css.css and added support for a special editor.css file that gets loaded by the wysiwyg editor in the administrator.
Template architecture in 1.5

For Joomla! 1.5 we wanted to fully separate the logic from the output. A template designer shouldn’t be restricted to the hardcoded output in the core, he should be able to override all the html generated by the modules and components to suit his needs.

To allow this kind of functionality Joomla! 1.5 implements a solution called a ‘template view‘ using a model-view-controller or MVC pattern. The implementation of this pattern is part of the new Joomla! Framework. Components and modules developed using this new API (application programming interface) can be automatically overridden by template designers.

The Joomla! 1.5 architecture makes a difference between two types of templates, the site templates and the extension templates. A site template defines the look and feel of your website while an extension template defines how a certain component or module gets rendered. The extension templates can be overridden in a site template.

Before we start building a first real world example of a 1.5 template I feel it’s important to explain the ‘template view’ approach a bit more in detail. The following part might be a bit technical, try to stick with me. It will hopefully give u a better understanding about templates, template engines and why things in Joomla! 1.5 are the way they are.
Template views

A Template View uses a template to implement the View portion of the Model View Controller pattern. A template is a document typically HTML with embedded markers which are replaced, manipulated, or evaluated via a template engine API to produce an output document. The purpose of a template is to isolate the HTML from the programming language code in a web application. There are several reasons for such a separation.

HTML Design and Application Programming are different roles on a web application development team, often performed by different people and at different points in time. Separating the HTML from the code gives each person their own file to work on.

When HTML was designed, it was never intended to be directly edited. Separating HTML from programming code allows the large body of WYSIWYG HTML editors to be used to edit template documents.

Simply separating HTML from programming code goes a long way toward isolating the presentation layer of an application. However, presentation logic complicates this isolation. Presentation logic consists of requirements such as “Show active menu item in red.”

A key design decision when using Template View is how to handle presentation logic. HTML was specifically not designed to be able to handle arbitrary logic (Principle of Least Power). To be able to handle arbitrary presentation logic, one must either augment the HTML or place the logic inside the program.

This is where template engines come in …
Template engines

Template engines were designed to allow the separation of business logic from the presentation of data. Template engines solve two major problems. How to achieve this separation, and how to separate “complex” php code from the HTML. In theory this allows HTML designers with no PHP experience to modify the look of the site without having to look at any PHP code.

Template engines introduce yet another level of processing. Not only do the template files have to be included, they also have to be parsed (depending on the template system, this happens in different ways - regular expressions, str_replaces, compiling, etc.). This is why template benchmarking came to be. Since template engines use a variety of different methods of parsing, some are faster and some are slower.

So basically what we have going on here is a scripting language (PHP) written in C used for the business logic. Inside the PHP code, you have yet another pseudo-scripting language to implement the presentational logic. Some template engines offer simple variable interpolation and loops. Others offer conditionals and nested loops. Still others offer an interface into pretty much all of PHP.

While patTemplate allows strict separation of business from presentation logic, there are still some problems. Basically, it just provides an interface to PHP with new syntax. When stated like that, it seems sort of silly. Is it actually more simple to write < pattemplate :tmpl name="row" loop="10"> … than < ? foreach($rows as $row) ... ?> ? We feel it isn’t.

For Joomla! 1.5 we are advocating to use PHP code as the template language of choice to implement presentation logic. We don’t believe that the PHP code a template designer needs to learn to create his presentational logic is more complex then learning the syntax of a template engine.
Where does that leave patTemplate ?

patTemplate was originaly choosen for it’s strictness, flexibility and xml declarative syntax. More info can be found in this old thread on the Mambo forums.

The problem with patTemplate is preformance. It doesn’t offer a decent compiling mechanism. We had originaly implemented it in Mambo 4.5.3 and preformance checks showed a huge increase in the page load. The major problem with patTemplate is that it can’t compile templates into PHP code as for example Smarty can which means that a template needs to be parsed and rendered every time a page is requested.

As a result we have decided not to use patTemplate in the core any more. The patTemplate library is still included in the Joomla! 1.5 framework for backwards compatibility reasons but we are not advocating it as the way forward.

Coming next : ‘How to build a site template in 1.5′

doctorin

Me he puesto a traducir este artículo. Creo que en un par de días la tendré a punto.

doctorin

Plantillas en Joomla! 1.5 - Parte 1

Publicado en el Centro de Ayuda y Documentación Joomla! Spanish

Por Johan Janssens,

Las plantillas han sido desde siempre uno de los puntos fuertes de Joomla!. La enorme cantidad de plantillas gratuitas y comerciales diseñadas para Joomla! 1.0 son la mejor prueba del éxito del sistema de plantillas de Joomla!. Tras el lanzamiento de la beta hemos recibido numerosas preguntas en los foros sobre los cambios en el sistema de plantillas de Joomla! 1.5 beta.

Pese a que la beta está pensada sólo para ser probada y revisada, nos damos cuenta de que los diseñadores necesitan más información para probar de verdad los cambios en las plantillas. En los foros los diseñadores nos han dicho que no podemos pretender que se lean el código para entender el nuevo sistema. ¡Y tienen toda la razón!

La próxima semana escribiré en el blog sobre los distintos cambios hechos. Intentaré responder a las múltiples preguntas que la gente ha posteado en los foros. Intentaré también explicar por qué se han cambiado ciertas cosas. En ocasiones, la información será algo técnica, pero creo que es importante que no sólo se comprenda el cómo sino también el porqué.

Comencemos...

COMPATIBILIDAD HACIA ATRÁS CON 1.0

Antes de entrar en materia hablemos sobre la compatibilidad hacia atrás. El nuevo sistema ha sido diseñado para ser completamente compatible hacia atrás con Joomla! 1.0. Si instala una plantilla de Joomla! 1.0 debe asegurarse de activar el ‘legacy mode’ (modo herencia) en la pestaña del servidor de la configuración global. Este modo carga toda la funcionalidad 1.0 que ha sido descartada en 1.5.

Tenga cuidado con los ajustes de los Módulos de Menú comparados con los ajustes predeterminados 1.0.x. En esta primera beta se muestran como una lista, lo cual rompe los menús por ejemplo en la plantilla ‘solarflare’. Cambie a Vertical u Horizontal según se necesite. Esto podría cambiar en la beta 2.

Se ha añadido de manera predeterminada un sufijo _menu en los parámetros de los módulos de menú. Esto se eliminará en la próxima beta para mantener la compatibilidad hacia atrás.

NOVEDADES EN LA VERSIÓN 1.5

Los cambios del sistema de plantillas de Joomla! 1.5 pueden dividirse en dos categorías. En primer lugar, hay cambios en la forma como se hacían las cosas en Joomla! 1.0; por ejemplo, la nueva manera de cargar los módulos. En segundo lugar hay un conjunto de nuevas características, como parámetros de plantilla…, echemos un vistazo rápido:

1. Cambios en las antiguas formas de trabajar

mosCountModules

La función mosCountModules ha sido reemplazada por la función $this->countModules y se ha añadido soporte para condiciones. Esto permite a los diseñadores contar fácilmente el número total de módulos en múltiples posiciones de la plantilla con una sola línea de código; por ejemplo, $this->countModules(’user1 + user2′) devolverá el número total de módulos en las posiciones user1 y user2.

Inclusión de salidas generadas por el núcleo

En Joomla! 1.0 se podían utilizar distintas funciones para incluir las salidas generadas por el núcleo. Todas esas funciones han sido sustituidas por el elemento < jdoc :include ... />. Por ejemplo, se pueden incluir módulos en una determinada posición mediante < jdoc :include type="modules" name="left" />.

Carga del editor

En Joomla! 1.0 usted debía cargar el editor en sus plantillas. Ahora ya no es necesario. Cuando el sistema procese la cabecera de su plantilla decidirá si el editor debe o no debe ser incluido.

2. Nuevas características

Parámetros de plantilla

Se pueden usar los parámetros de plantilla para permitir a los administradores controlar la estructura de la plantilla. Funcionan de una manera muy parecida a los parámetros de módulo. Un diseñador de plantillas puede definir configuraciones adicionales para una plantilla en su archivo xml, y el administrador del sitio puede ajustarlas en el administrador de plantillas. Por ejemplo, los administradores pueden cambiar los esquemas de color, elegir entre una maquetación de 2 ó 3 columnas, o elegir la anchura mínima de la plantilla.

La plantilla prevalece

Las plantillas pueden anular la forma predeterminada de generar las salidas por parte del núcleo. Por ejemplo, usted podría cambiar la manera de representar un artículo y cambiar la estructura de tablas por divs; o puede cambiar una clase o id a su gusto. También se pueden ampliar la paginación y los estilos de módulo.

Soporte para múltiples archivos css

El gestor de plantillas soporta múltiples archivos css, así que no es necesario incluir toda la css en un único archivo. También hemos cambiado el nombre del archivo css principal a template.css en lugar de template_css.css y hemos añadido soporte para un archivo especial editor.css que es cargado por el editor WYSIWYG en el administrador.

doctorin

ARQUITECTURA DE PLANTILLAS EN LA VERSIÓN 1.5

Para Joomla! 1.5 queríamos separar completamente el código de la salida. Un diseñador de plantillas no debería estar limitado a las posibilidades programadas en el núcleo, debería poder sustituir todo el html generado por los módulos y componentes para adecuarlo a sus necesidades.

Para permitir esto Joomla! 1.5 dispone de una solución llamada ‘vista de plantilla’ mediante un patrón Modelo-Vista-Controlador o MVC. La incorporación de este patrón es parte del nuevo entorno de trabajo de Joomla!. Los componentes y módulos desarrollados con esta nueva API (Interfaz de Programación de Aplicaciones) pueden ser sustituidos de manera automática por los diseñadores de plantillas.

La arquitectura de Joomla! 1.5 diferencia dos tipos de plantillas: plantillas de sitio y plantillas de extensión. Un plantilla de sitio define el aspecto y manejo de su sitio web, mientras que una plantilla de extensión define cómo se representa un determinado componente o módulo. Las plantillas de sitio pueden anular a las plantillas de extensión.

Antes de empezar a construir un primer ejemplo práctico de una plantilla 1.5, creo que es importante explicar el planteamiento de la “vista de plantilla” con más detalle. La siguiente sección puede que sea algo técnica, intente seguirme. Espero que le permita entender mejor las plantillas, motores de plantillas y por qué en Joomla! 1.5 las cosas son como son.

VISTAS DE PLANTILLA

Una vista de plantilla utiliza una plantilla para ejecutar la parte Vista del patrón Modelo-Vista-Controlador. Una plantilla es un documento típicamente HTML con marcadores incrustados que son sustituidos, manipulados o evaluados mediante un motor API de plantilla para producir un documento de salida. El propósito de una plantilla es aislar el HTML del código del lenguaje de programación en una aplicación web. Hay varias razones para tal separación.

El Diseño HTML y la Programación de Aplicaciones son distintas funciones dentro de un equipo de desarrollo de aplicaciones web, representadas a menudo por personas diferentes y en diferentes momentos. Separar el HTML del código proporciona a cada persona su propio fichero sobre el que trabajar.

Cuando se diseñó el HTML, no se pretendía que fuera editado directamente. Separar el HTML del código de programación permite al gran grupo de editores WYSIWYG HTML ser usados para editar documentos de plantilla.

El simple hecho de separar el HTML del código de programación supone un gran avance hacia el aislamiento de la capa de presentación de una aplicación. Sin embargo, la lógica de presentación complica este aislamiento. La lógica de presentación consiste en requerimientos como “Mostrar el elemento activo del menú en rojo”.

Una decisión de diseño clave cuando se usa la Vista de Plantilla es cómo manejar la lógica de presentación. El HTML no se diseñó de manera específica para ser capaz de trabajar con lógica arbitraria (Principio de la Mínima Potencia). Para poder trabajar con lógica de presentación arbitraria, se debe extender el HTML o situar la lógica dentro del programa.

Aquí es donde hacen su aparición los motores de plantilla…

MOTORES DE PLANTILLA

Los motores de plantillas se diseñaron para permitir separar la parte lógica de la presentación de los datos. Los motores de plantilla resuelven dos grandes problemas: cómo conseguir esta separación y cómo separar código PHP “complejo” del HTML. En teoría, esto permite que los diseñadores HTML sin experiencia en PHP puedan modificar el aspecto del sitio sin tener que mirar el código PHP para nada.

Los motores de plantilla introducen un nuevo nivel de procesamiento. Los archivos de plantilla no sólo tienen que estar presentes, sino que también deben ser procesados (dependiendo del sistema de plantillas, esto ocurre de distintas formas: expresiones regulares, str_replaces, compilando, etc.). Esta es la razón por la cual han aparecido las pruebas de rendimiento de plantillas. Dado que los motores de plantilla emplean diversos métodos de procesado, algunas son más rápidas y otras más lentas.

Así que, básicamente, lo que tenemos ahora es un lenguaje interpretado (PHP) escrito en C usado para la parte lógica. Dentro del código PHP, todavía hay otro lenguaje pseudointerpretado para realizar la lógica de presentación. Algunos motores de plantilla permiten simplemente interpolación de variables y bucles; otros ofrecen condicionales y bucles anidados; algunos incluso una interfaz hacia casi todas las posibilidades de PHP.

Aunque patTemplate permite una separación estricta entre la lógica estructural y la de presentación, todavía existen algunos problemas. Básicamente, se limita a proporcionar un interfaz para PHP con nueva sintaxis. Dicho así, parece una tontería. ¿Es realmente más sencillo escribir < pattemplate :tmpl name="row" loop="10"> … que < ? foreach($rows as $row) ... ?> ? Pensamos que no.

Para Joomla! 1.5 somos partidarios de usar código PHP como lenguaje de plantillas de elección para la lógica de presentación. No creemos que el código PHP que un diseñador necesita aprender para crear su lógica de presentación será más complejo que aprender la sintaxis de un motor de plantilla.

¿DÓNDE DEJA ESTO A PATTEMPLATE ?

patTemplate se eligió originalmente por su consistencia, flexibilidad y sintaxis declarativa xml. Se puede encontrar más información en su viejo hilo de los foros de Mambo.

El problema con patTemplate es su rendimiento. No ofrece un mecanismo de compilación decente. Lo habíamos incorporado originalmente en Mambo 4.5.3 y las pruebas de rendimiento mostraron un tremendo incremento en la carga de las páginas. El principal problema de patTemplate es que no puede compilar plantillas en código PHP como, por ejemplo, puede hacer Smarty, lo cual significa que una plantilla necesita ser procesada y representada cada vez que se solicita una página.

Como resultado, hemos decidido no usar nunca más patTemplate en el núcleo. La biblioteca patTemplate todavía se incluye en el entorno de trabajo de Joomla! 1.5 por razones de compatibilidad hacia atrás, pero no la consideramos una opción de futuro.

Próximamente : ‘Cómo Construir una Plantilla de Sitio en Joomla! 1.5′

_____________

Texto Original: 'Templates in Joomla! 1.5 - Part 1', por Johan Janssens (Blog del Desarrollador de Joomla!)