Buenas prácticas de maquetación en Liferay

13/09/2016 Tweet
Buenas prácticas de maquetación en Liferay

A la hora de realizar una maqueta debemos tener en cuenta una serie de pautas a nivel general como puede ser comentar el código, retear estilos, validar el código, reutilizar código,... Pero además, cuando la maqueta tiene que ser integrada en un gestor de contenidos o portales (CMS), hay que conocer sus peculiaridades y tenerlas en cuenta para no tener resultados inesperados. En este caso nos vamos a centrar en Liferay.

1. Maquetación modular

En muchos gestores de contenido, y en concreto en Liferay, las páginas HTML que se sirven al usuario final se construyen dinámicamente uniendo distintos componentes independientes. En este caso se hace necesario dividir el contenido HTML en secciones o módulos a través de capas totalmente independientes en cuanto a estilos se refiere. En Liferay a estos módulos o secciones se les llama Portlets.

Esto significa que los estilos de cada módulo deben ser únicos y no heredar estilos de otros componentes. De esta forma aseguramos que cada componente se visualice correctamente independientemente del layout donde se coloque y de los otros componentes que tenga alrededor en la página.

2. Decidir el tema padre

En Liferay existe lo que se llama Temas (Themes). Estos permiten cambiar el Look & Feel de nuestras páginas. Cada tema está formado por un conjunto de directorios que contienen archivos css, imágenes, javascripts, xmls,…

Liferay tiene por defecto algunos temas pero también podemos crear los nuestros propios. Para facilitar el desarrollo y no tener que empezar de cero, podemos usar cualquiera de ellos como tema padre. Esto significa que podemos definir una apariencia por defecto heredando sus estilos, imágenes, scripts,… para luego definir de forma más específica aquello que queramos cambiar.

Esto puede ser muy útil cuando el diseño de nuestro portal es similar a alguno de esos temas y tan sólo tenemos que hacer algunas adaptaciones. Sin embargo, cuando el diseño dado es completamente diferente estaremos constantemente sobrescribiendo estilos y funcionalidades que vengan heredadas. Por ello en algunas ocasiones es recomendable empezar incluso de cero.

Por tanto, hay que analizar y valorar cuál es el tema qué mejor se adapta a nuestras necesidades, de lo contrario, en lugar de ayudar y minimizar tiempos finalmente puede llegar a ser un inconveniente y no conseguir el resultado deseado.

3. Estructura de carpetas y ficheros del tema

En la carpeta raíz de docroot tenemos las carpetas base del tema del que hemos heredado. Por defecto viene con las siguientes hojas de estilo:

Estructura carpetas ficheros theme en Liferay

Por otro lado tenemos la carpeta diffs (dentro de docroot). Para modificar el tema y sobrescribir estilos debemos crear la misma estructura de directorios dentro de esta. Así, siempre que deseemos modificar aquello que viene por defecto en un tema (imágenes, hojas de estilos, javascript,...) debemos trabajar y modificar los archivos que hay dentro de ésta. Sólo así nuestros cambios tendrán efecto.

4. Librería AlloyUI

Librería AlloyUI de Liferay

Liferay incluye su propia librería JavaScript, AlloyUI, se basa en YUI3:

http://alloyui.com

Conocer esta librería y qué ofrece nos va a permitir sacar mejor partido a este gestor de contenidos. Ofrece una serie de módulos y funcionalidades que nos puede ahorrar mucho tiempo de desarrollo: ventanas modales, sliders, calendarios, tooltips,… y mucho más. Aquí podemos ver algunos ejemplos:

http://alloyui.com/examples/

5. Portales responsive con Bootstrap

Bootstrap para Liferay

Liferay incluye la librería de Bootstrap para crear nuestros portales responsive. La versión que se incluye es la 2.x y no la 3.x.

Un error muy común es crear nuestras maquetas con la versión más actualizada de Bootstrap y al integrarla en Liferay nos encontrarnos con la versión anterior. El comportamiento y las clases que se renderizan son diferentes por lo que nuestra maquetación no valdría.

6. Diferenciar imágenes de contenido

A menudo se añaden imágenes como fondo de elementos <p>, <div>, <a>, etc. ya que resultan más manejables y fáciles de modificar.

Sin embargo cuando se trata de imágenes que forman parte del contenido (foto de la ficha de un producto, foto del autor de un libro, banners, etc.) sus rutas deben de ir en el archivo HTML en tags . De este modo serán gestionables por la herramienta CMS y por el usuario contribuidor.

Esto no es específico de Liferay pero no está de menos decir lo importante que es tener claro a la hora de maquetar, qué imágenes van a ser gestionables y cuáles no.

7. Clases css propias de Liferay

Liferay genera dentro de la estructura html sus propias clases. Conocerlas nos puedes ayudar a maquetar, aquí indico algunas de ellas:

Clases que en la etiqueta <html>

Entre otras clases, liferay añade dentro de esta etiqueta, clases que nos indican el navegador que estamos utilizando así como su versión.

Por ejemplo, si cargamos nuestro portal con el navegador Firefox en Window, Liferay generará las siguientes clases: firefox firefox40 win.

En el caso de Chrome nos añadirá las clases: chrome chrome45 chrome45-0 win

Y para el caso de Internet Explorer añadirá: ie ie11 ie11-0 win

Esto nos puede ser muy útil para solucionar las diferencias entre navegadores a la hora de maquetar

Clases que en la etiqueta <body>

En el body nos podemos encontrar clases que nos indican si se trata de una página pública o privada, si estamos logados o no

Clases para cada porlet

Los portlets en Liferay, como ya hemos dicho, son módulos o secciones independientes que componen nuestras páginas. A nivel de código, contienen libremento lo que necesitemos funcionamente pero al mismo tiempo este va contenido en una estructura html concreta:

<div class="portlet-boundary portlet-borderless">
<div class="portlet-borderless-container">
<div class="portlet-body">
Aquí el código del portlet
</div>
</div>
</div>

8. Liferay y Angular

Podemos hacer uso de Angularjs pero tenemos que tener en cuenta algunas incompatibilidades

El principal problema parece estar en el atributo ng-app de Angularjs. Este framework utiliza este atributo para arrancar, viene a ser como el document.ready de jquery, y se suele poner en la etiqueta <html> por lo que Angular asume que sólo hay uno. Si consideramos los portlets de Liferay como mini aplicaciones independientes deberíamos tener un atributo ng-app en cada uno de ellos. Aquí es donde empezarían los conflictos. Sin embargo, haciendo uso de la etiqueta de Liferay y del método de bootstrap (angular.bootstrap), hay solución.

Dejo aquí unos posts de referencia. En cualquiera de ellos la conclusión final es que, Liferay y Angular son compatibles: