Cuando queremos crear un Theme en Liferay en muchas ocasiones nos podemos encontrar con que los estilos aui entran en conflicto con los estilos que nosotros queremos aplicar. Un caso típico es el choque producido entre el bootstrap que utiliza aui y bootstrap 3.
¿Cómo podemos mantener los estilos Liferay para el propio Liferay sin que afecte a los estilos de nuestra web?
Pues no existe una fórmula mágica, pero podemos mitigar el impacto y que al menos desde fuera no se aprecien los conflictos.
Para ello haremos que los estilos aui no se apliquen a partir de la class “aui” (que se encuentra al inicio, en el <html>) sino a un nivel más bajo.
Esto lo podemos lograr mediante el Theme, modificando el fichero “aui.css” y añadiéndolo a “_diffs/css/”:
_diffs\css\aui.css:
.aui .lfr-styles {
...
}
Cambiando .aui {…} por .aui .lfr-styles {…} provocamos que los estilos aui no se apliquen hasta que se encuentre algún elemento con la class lfr-styles, de este modo podemos controlar qué bloques queremos que usen estos estilos.
Como he dicho anteriormente esto sirve para mitigar los conflictos, pero no es perfecto y en el proceso podemos perder estilos genéricos (aui). Por ejemplo, si tenemos un “font-family” que antes aplicaba a “.aui body”, ahora aplicaría a “.aui .lfr-styles body”, si donde colocamos ese “.lfr-styles” está por debajo del body (que como veremos más adelante será lo más normal) ese estilo no se aplicaría.
Con este sistema algún estilo aui propio de Liferay podría verse afectado pero nuestra web y nuestros estilos custom estarían libres de conflictos.
Ahora, para poder seguir utilizando aui en lo que a Liferay se refiere (los portlets propios) podemos usar el mismo Theme y el Hook.
Desde el Theme, si queremos ahorrarnos trabajo del Hook, podemos hacer que aplique también los estilos directamente a los popup generados por Liferay donde se incluiría: el menú de configuración de los portlet, el seleccionar web contents, exportar/importar un portlet, seleccionar estructura o plantilla, etc.
Esto se puede conseguir añadiendo a la línea anterior otra class que está presente en este tipo de contenidos:
_diffs\css\aui.css:
.aui .lfr-styles, .aui .portal-popup{
...
}
Por otro lado, desde el Hook podemos incluir la class antes mencionada a los portlets propios de Liferay que queremos que continúen usando la clase aui. A continuación listamos los más típicos, y que archivo necesitaríamos modificar:
- Menu Liferay (Dockbar): \html\portlet\dockbar\view.jsp
- Menu Liferay: add, edit, preview (Dockbar): \html\js\liferay\dockbar.js
- Add WebContent, Edit WebContent (Journal): \html\portlet\journal\edit_article.jsp
- Look and Feel (Portlet CSS): \html\portlet\portlet_css\view.jsp
El proceso para los jsp suele ser el mismo, usaremos uno de ejemplo:
\html\portlet\dockbar\view.jsp:
<%@ taglib uri="http://liferay.com/tld/util" prefix="liferay-util" %>
<%@ taglib uri="http://liferay.com/tld/theme" prefix="liferay-theme" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<liferay-theme:defineObjects />
<liferay-util:buffer var="html">
<liferay-util:include page="/html/portlet/dockbar/view.portal.jsp" useCustomPage="false" />
</liferay-util:buffer>
<div class="lfr-styles">
<%= html %>
</div>De esta forma incluimos un div por encima del contenido que queremos que use aui con nuestra nueva class.
En el caso del dockbar.js lo usamos por simplificar, ya que añadiendo nuestra class a tres líneas de código nos ahorramos hookear tres jsp.
\html\js\liferay\dockbar.js:
var TPL_ADD_CONTENT = '<div class="lfr-add-panel lfr-admin-panel lfr-styles" id="{0}" />';
var TPL_EDIT_LAYOUT_PANEL = '<div class="lfr-admin-panel lfr-edit-layout-panel lfr-styles" id="{0}" />';
var TPL_PREVIEW_PANEL = '<div class="lfr-admin-panel lfr-device-preview-panel lfr-styles" id="{0}" />';
Se pueden buscar atajos o simplificaciones, pero la cuestión es lograr incluir nuestra clase para que aui afecte sólo al contenido que nosotros queremos que afecte y no provoque conflictos en lo que ve el usuario, que al fin y al cabo, es para el que está pensado nuestro diseño.
Espero que os sirva de ayuda. Como he comentado al principio no es la solución perfecta, pero cuando tienes que forzar 25 estilos para que un simple botón se vea como tú quieres (estilos por defecto, estilos hover, active , focus, responsive, shadows, …) el reducir estos conflictos te pueden ahorrar mucho tiempo y dolores de cabeza.
Saludos.