Entrades amb etiqueta aui .

Minimizando conflictos de aui en nuestros Themes de Liferay

Data de publicació 28/09/16 18:03

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.

Liferay Model Hints

Data de publicació 14/11/14 04:36

Una vez, con el Service Builder, hayas creado tus entidades y la implementación del modelo de negocio de tu portal, es interesante especificar como se deberían presentar los datos al usuario (de las entidades creadas).

Con los Model Hints puedes especificar esta información y, además, puedes marcar el tamaño de los campos en la base de datos.

Estas modificaciones se han de realizar en el archivo 'portlet-model-hints.xmlque se encuentra en la ruta: ‘docroot/WEB-INF/src/META-INF’.

Los Model Hints te permiten configurar la librería de tags AlloyUI ‘aui’ para mostrar los campos de tu modelo de negocio.

Ejemplo de uso
Con esta entidad creada con el Service Builder (archivo ‘service.xml’):
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 6.2.0//ES"
      "http://www.liferay.com/dtd/liferay-service-builder_6_2_0.dtd">
<service-builder package-path="com.proliferay.servicebuilder">
    <author>duvidu</author>
    <namespace>PERSONAS</namespace>
    <entity name="Persona" table="PERSONA" local-service="true" remote-service="true">
        <column name="personaId" type="long" primary="true" />
        <column
name="Nombre" type="String" />
        <column
name="Apellido" type="String" />
        <column
name="DNI" type="String" />
        <column
name="fechaNacimiento" type="Date" />
        <column
name="observaciones" type="String" />
    </entity>
</service-builder>

 

Se autogenera el archivo ‘portlet-model-hints.xml’:

<?xml version="1.0"?>
<model-hints>
    <model name="
com.proliferay.servicebuilder.model.com.profilerayersona
           table="PERSONAlocal-service="trueremote-service="true">
        <column name="personaIdtype="longprimary="true" />
        <column 
name="Nombretype="String" />
        <column 
name="Apellidotype="String" />
        <column 
name="DNItype="String" />
        <column 
name="fechaNacimientotype="Date" />
        <column 
name="observacionestype="String" />
    </entity>

</model-hints>

 

Quiero limitar en un campo fecha que los usuarios solo puedan introducir fechas pasadas, como la de nacimiento. Entonces en el archivo 'portlet-model-hints.xml' marcamos para el campo ‘fechaNacimiento’ un hint llamado ‘year-range-future’ a falso:

<?xml version="1.0"?>
<model-hints>
    <model name="
com.proliferay.servicebuilder.model.com.profilerayersona
           table="PERSONAlocal-service="trueremote-service="true">
        <column name="personaIdtype="longprimary="true" />
        <column 
name="Nombretype="String" />
        <column 
name="Apellidotype="String" />
        <column 
name="DNItype="String" />
        <column 
name="fechaNacimientotype="Date" >
             <hint name="year-range-future">false</hint>
        </
column>
        <column 
name="observacionestype="String" />
    </entity>

</model-hints>

 

Para que este cambio sea efectivo se ha de hacer un Build Service.

Así, si tuviéramos un formulario para introducir fechas para el nacimiento con los tags aui, no permitiría introducir fechas futuras.

Como hemos dicho, con los Model Hints también puedes modificar el tamaño de un campo en la Base de Datos. Si fuera el caso de que necesitáramos que el campo ‘observaciones’ fuera más grande que el por defecto entonces usamos el ‘max-length’:

<?xml version="1.0"?>
<model-hints>
    <model name="
com.proliferay.servicebuilder.model.com.profilerayersona
           table="PERSONAlocal-service="trueremote-service="true">
        <column name="personaIdtype="longprimary="true" />
        <column 
name="Nombretype="String" />
        <column 
name="Apellidotype="String" />
        <column 
name="DNItype="String" />
        <column 
name="fechaNacimientotype="Date" >
             <hint
name="year-range-future">false</hint>
        </
column>
        <column 
name="observacionestype="String" >
             <hint name="max-length">400</hint>
        </
column>
    </entity>
</
model-hints>

 

Recuerda hacer el Build Service y el Deploy para que se propague el cambio a la Base da Datos y podrás ver como el campo ha cambiado.

La lista completa de Model Hints es la siguiente:

modelhints.png

¡Espero que os sirva de ayuda!

Bloggers recents Bloggers recents

Oscar Rodríguez
Apunts: 9
Estrelles: 2
Data: 28/09/16
David Berruezo
Apunts: 14
Estrelles: 1
Data: 22/07/16
Javi Martín
Apunts: 2
Estrelles: 1
Data: 20/05/16
Javier Torres
Apunts: 5
Estrelles: 3
Data: 11/04/16
Sergi Mingueza
Apunts: 4
Estrelles: 1
Data: 19/10/15
Matilde Gallardo
Apunts: 1
Estrelles: 0
Data: 26/02/15
Adrià Vilà
Apunts: 4
Estrelles: 4
Data: 31/08/14
Elena Ruiz
Apunts: 1
Estrelles: 2
Data: 13/03/14