Liferay 6.2: Desarrollo de Plugins (Parte 1)

Liferay 6.
2
Desarrollo de Plugins (Parte 1)
Instalación
 Instalar JDK 1.7
 URL Bundle y SDK:
• https://sourceforge.net/projects/lportal/files/Liferay%20Portal/
6.2.5%20GA6/
 Descargar:
• liferay-plugins-sdk-6.2-ce-ga6-20160112152609836.zip
• liferay-portal-tomcat-6.2-ce-ga6-20160112152609836.zip
 URL Liferay IDE:
• https://sourceforge.net/projects/lportal/files/Liferay%20IDE/2.2.4%
20GA5/
 Descargar:
• liferay-ide-eclipse-windows-x64-2.2.4-ga5-201507230603.zip
Instalación
 Descomprimir el archivo de eclipse: liferay-ide-eclipse-
windows-x64-2.2.4-ga5-201507230603.zip
 Descomprimir el archivo liferay-plugins-sdk-6.2-ce-ga6-
20160112152609836.zip en el directorio del eclipse
Instalación
 Descomprimir el archivo: liferay-portal-tomcat-6.2-ce-
ga6-20160112152609836.zip
Instalación
 Configurar Plugin SDK
Instalación
 Configurar Runtime Environment
Instalación
 Configurar Nuevo Servidor
Instalación
 Ajustes finales:
• Editar: <PLUGIN_SDK_PATH>\build.properties
• Cambiar el valor del parámetro "ivy.jar.url", para que apunte a
la siguiente URL:
ivy.jar.url=https://repository.liferay.com/nexus/content/repo
sitories/liferay-public-
snapshots/com/liferay/org.apache.ivy/${ivy.version}/org.apac
he.ivy-${ivy.version}.jar
Plugins
 Actualmente existen 6 tipos de plugins:
• Portlets
• Themes
• Layout Templates
• Web Modules
• Hooks
• Ext Plugins
Plugins
 Plugins SDK:
• Entorno simple para el desarrollo de plugins de Liferay
• El desarrollo de portlets, themes y layouts se llevaba a
cabo en el ambiente Ext.
• Desde Liferay 6.0, el EXT environment no es soportado,
ya que fue reemplazado por los hot-deployables
portlets, themes y layouts.
• Plugins SDK requiere que un bundle de Liferay Portal
esté presente para compilar contra los jars incluidos en
el portal.
Developer’s Liferay Portal +
Plugins
Hot Deploy App Server
SDK
Folder Bundle
Plugins
 Plugins SDK:
Componente Directorio
Portlets /portlets
Themes /themes
Layouts /layouttpl
Web applications /web
Hooks /hooks
Ext plugins /ext
Ant scripts / (scripts para la generación de los componentes)
Plugins
Portlets
 Los portlets desarrollados en el plugin SDK solamente pueden

importar clases desde:
<LIFERAY_BUNDLE>\tomcat-7.0.62\lib\ext\portal-service.jar y otros
jars contenidos en el directorio WEB-INF/lib del portlet
 Archivo <nombre_proyecto>/docroot/WEB-INF/liferay-plugin-
package.properties permite referenciar (importar) librerías de
Liferay, para importar librerías externas o propias, se deben
copiar al directorio <nombre_proyecto>/docroot/WEB-INF/lib
 Los portlets pueden hacer uso de cualquier framework de

aplicaciones que soporte Liferay
Portlets
 Hay dos estándares que gobiernan el comportamiento de
portal/portlet
 JSR-168 -> Especificación de la versión 1.0 de portlets,

creada con el fin de permitir desplegar múltiples
aplicaciones en una sola página
 JSR-286 -> En la segunda versión de portlets, se agregaron

características como:
• Manejo de eventos (se aumentó el ciclo de vida del portlet)
• Inter-portlet communication
Portlets
 Los portlets deben proveer un archivo web.xml
válido, a pesar de que el proceso hot deploy de
Liferay hace la mayoría del trabajo de configuración
de este archivo
 Además del archivo web.xml, los portlets necesitan el
archivo descriptor: portlet.xml
 El archivo portlet.xml le dice al contenedor:
• Qué portlets están incluidos en la aplicación
• Qué roles soportan
• Qué portlet modes soportan
Portlets
 Características claves de los portlets:
• Sólo son responsables de renderizar un fragmento de la
página total, por lo tanto ciertos tags no son permitidos:
<html>, <head>, <body>
• El lugar correcto donde debe ir inserto un portlet es en el
BODY
• Los portlets podrían necesitar ser re-renderizados, inclusive si
un usuario no interactúa con el
• En tiempo de diseño, no hay forma de saber qué página
desplegará un portlet, y qué otros portlets podrían estar en
esa página, por lo tanto es impráctico crear URLs de portlets
directamente
• La API de portlets provee métodos para crear todo lo
necesario de URLs de portlets
Portlets
 Diferencias con los Servlets:
• Los servlets tienen acceso al objeto ServletRequest, los
portlets no tienen acceso a este objeto, sino que al
objeto PortletRequest
• Debido a lo anterior, los portlets no son capaces de leer
query parameters directamente desde la URL.
• La especificación solo provee un mecanismo para que
los portlets puedan leer sus propios parámetros de URL,
u otros que hayan sido declarados como Public Renders
Parameters
• Liferay de todas formas provee métodos utilitarios para
acceder al ServletRequest y consultar parámetros.
Portlets
 Fases de los portlets:
Portlet Cuando se ejecuta
init() Se ejecuta al deployarlo. Inicializa el portlet
render() Al agregarlo a la página, pintarlo, y también al realizar
acciones (al pasar por el processAction()) se renderiza
nuevamente (refresca el portlet completo). Renderiza el
contenido
processAction() Diferentes acciones que podría realizar el usuario al usar el
portlet. Llamado cuando el usuario realiza una acción
processEvent() -> (JSR-286) Llamado cuando un evento ha sido gatillado

serverResource() -> (JSR-286) Llamado cuando una ResourceURL es solicitada
destroy() Al remover el portlet del servidor de aplicaciones. Libera el
objeto portlet, de manera que sea elegible por el garbage
collector
Portlets
 Los portlets están diseñados para coexistir en la
misma página con otros portlets, por lo que una
interacción de un usuario con un portlet
directamente, podría generar una solicitud sobre otro
portlet con el que el usuario no estaba interactuando
 Por lo tanto, los portlets poseen más de un tipo de

método para procesar las solicitudes, y estos
métodos se corresponden con las fases del portlet
Portlets
Fases de los Portlets
 INIT PHASE:
• Llamado por el contenedor durante el despliegue del portlet

• Durante esta fase típicamente se inicializan recursos, o se
realizan actividades que se requieren una sola vez
• Los portlets típicamente usan el método init() para leer
parámetros de inicialización desde el archivo portlet.xml
Portlets
 RENDER PHASE:
• En esta fase el portlet genera contenido basado en su

estado actual
• Esta fase es llamada en todos los portlets de la página
cuando la página es renderizada
• También es llamada cuando cualquiera de los portlets en
esa página completan las fases Action, o Event Processing
• Aquí también se pueden ejecutar acciones (es mas rápido
que el Process Action, ya que solo renderiza, el Process
Action ejecuta dos métodos Process Action y Render)
Portlets
 RENDER PHASE:
• Los portlets típicamente ingresan a la fase Render cuando se recarga la

página, después de completar una acción
• Es posible gatillar la fase Render directamente, invocando la URL Render de
la siguiente forma:
 <a href=”<portlet:renderURL/>”>Click to invoke Render Phase</a>
• URL Generada:
 <a
href="http://localhost:8080/group/guest/parts?p_p_id=jsr286demoportlet_
WAR_jsr286demoportlet_INSTANCE_A2Gc9caIEGIx&p_p_lifecycle=0&
amp;p_p_state=normal&p_p_mode=view&p_p_col_id=column-
1&p_p_col_count=1">Click to invoke Render Phase</a>
Portlets
 RENDER PHASE:
Portlets
 ACTION PHASE:
• Se ingresa a esta fase como resultado de la interacción de

un usuario con el portlet
• Específicamente, la interacción del usuario debería resultar
en el cambio del estado en el portlet
• Una vez que la Action Phase ha finalizado, el portlet
procesa cualquier evento que haya sido gatillado por la
Action Phase
• Una vez que los eventos han sido procesados , o si no fue
lanzado ningún evento, el portal llama a la Render Phase
en todos los portlets de la página
Portlets
 ACTION PHASE:
 Los portlets ingresan a la Action Phase mediante la

invocación de una URL, que puede generarse de la
siguiente forma:
 <a href="<portlet:actionURL/>">Click to invoke

Action Phase</a>
Portlets
 ACTION PHASE:
• URL Generada:
 <a
href="http://localhost:8080/group/guest/parts?p_auth=DccEXRwN&p_
p_id=jsr286demoportlet_WAR_jsr286demoportlet_INSTANCE_A2Gc9caIEG
Ix&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&a
mp;p_p_col_id=column-1&p_p_col_count=1">Click to invoke Action
Phase</a>
• Ej:
Portlets
 EVENT PHASE:
• Fase utilizada para procesar cualquier evento que haya

sido lanzado durante la Action Phase del ciclo de vida del
portlet
• Los eventos son utilizados por Inter Portlet
Communication (IPC)
• Los eventos a su vez pueden lanzar eventos adicionales
• Una vez que todos los eventos han sido procesados, el
portal llamará a la Render Phase en todos los portlets de la
página
Portlets
 RESOURCE SERVING PHASE:
• Esta fase permite a los portlets servir contenido

dinámico sin necesidad de llamar a la Render Phase en
todos los portlets en la página
• En Portlet 1.0, las solicitudes de los portlets siempre
retornaban una página de portal completa
• Un recurso es solicitado vía una ResourceURL
• Los bytes escritos en la respuesta son enviados
directamente al cliente
Portlets
• Útil para:
 Crear imágenes y otros binarios dinámicamente
 Retornar XML, JSON, fragmentos HTML de llamadas
Ajax, etc.
• Los portlets entran en la fase invocando una Resource URL
que puede generarse de la siguiente forma:
 <a href=""
onclick="loadXMLDoc('<portlet:resourceURL/>'); return
false">Click to invoke Resource Serving Phase</a>
Portlets
• URL Generada:
 <a
onclick="loadXMLDoc('http://localhost:8080/group/guest/parts?p_
p_id=jsr286demoportlet_WAR_jsr286demoportlet_INSTANCE_A2G
c9caIEGIx&p_p_lifecycle=2&p_p_state=normal&p_p
_mode=view&p_p_cacheability=cacheLevelPage&p_p_c
ol_id=column-1&p_p_col_count=1'); return false" href="">Click
to invoke Resource Serving Phase</a>
Portlets

Portlets
 DESTROY PHASE:
• El método destroy() es llamado por el contenedor de

portlets cuando el portlet es removido de servicio
• Está diseñada para permitir al portlet liberar cualquier
recurso, y guardar el estado si es necesario
• Para gatillar el método destroy() es necesario
undeployar el portlet
Portlets
Características de los Portlets
 Portlet Modes
 Windows States
 Portlet Preferences
 Standard Inter Portlet Communication (IPC)
• Public Render Parameters
• Events
 Resource Serving
• AJAX Support
• Binary Data Support
Portlets
 Portlet Modes
• Cada portlet tiene un modo actual, el cual indica la función que está
realizando
• Todos los portales compatibles con Java deben soportar los modos View,
Edit y Help
• Los portlet modes son definidos en el archivo portlet.xml
 En el Edit Mode, las configuraciones son representadas como un set
persistente de pares nombre-valor, y son llamadas «portlet preferences».
Portlets
 Portlet Modes
• Look and Feel Mode
(Liferay Extension)
• Configuration Mode
(Liferay Extension)
Portlets
 Windows States
• Indican la cantidad de espacio que ocupará el portlet
en la página
• Todos los portales compatibles deben soportar los
estados: minimizado, maximizado y normal
Portlets
 Remove Window
• Liferay provee la opción de remover el portlet de la
página mediante la opción “Remove”
Portlets
Desarrollo de Portlets
 Liferay Portlet
• Liferay agrega dos descriptores más que extienden
las opciones de portlet.xml:
 liferay-portlet.xml
 liferay-display.xml
• Estos archivos son opcionales, y permiten

implementar características propias de Liferay
Portlets
 liferay-portlet.xml
 liferay-display.xml
Portlets
 Liferay Portlet
 También es posible agregar el archivo liferay-plugin-
package.properties, para describir las versiones de
Liferay que son compatibles con el portlet, como así
también otras opciones.
Portlets
 Ejercicio: Creación de Portlet Básico

• Crear un portlet que despliegue una página de saludo
(modo View).
• El nombre de la persona a saludar deberá poder ser
configurado en el modo Edit (portlet preferences).
Portlets
 Ejercicio, pasos a seguir:

• Crear proyecto de tipo Liferay Plugin Project
• Nombre del proyecto: hello-world
• Crear Portlet con framework Liferay MVC, con
superclase javax.portlet.GenericPortlet
• El portlet debe definir los modos View y Edit
• Debemos implementar el método processAction para
procesar el formulario
• Utilizar los snippets: PortalDev-01-Standard Portlet
Exercise
Portlets
 Tip:
 También es posible configurar múltiples métodos que procesan acciones (no
solo processAction), de la siguiente forma:
 Llamada:
 Es importante eliminar el método “processAction”, ya que si está presente

siempre pasará por éste, y no por los métodos configurados.
Portlets
Inter Portlet Communication (IPC)
 Es introducido en Portlet 2.0 (JSR-286), y define dos

diferentes métodos de IPC
 Es importante para Portlet Applications, las cuales
son aplicaciones que están compuestas de más de un
portlet para su funcionamiento
 Ej.: Una aplicación que muestra facturas, y que
requiera un portlet de búsqueda de clientes en su
cabecera, que al seleccionar el cliente despliega las
facturas en otro portlet mas abajo).
 Con IPC lo descrito anteriormente es posible hacerlo
en forma estándar, e incluso no requiere que los
portlets estén en la misma página.
Portlets
 Método 1: Public Render Parameters

• Son el método estándar simple para IPC
• Es posible declarar una lista de parámetros públicos
para una portlet application en el archivo portlet.xml
• Los nombres de los parámetros deben ir con
namespace para evitar conflictos
• Ej.:
Portlets

• Los portlets deben declarar qué parámetros públicos
quieren leer, utilizando el tag : <supported-public-
render-parameter>
• Los parámetros públicos siempre son de tipo “String”
• Ej.:
• Pueden obtenerse utilizando el siguiente Map:

Portlets

• Los parámetros son mezclados con los parámetros regulares, de
manera que pueden ser leídos utilizando el método
request.getParameter(name) o también
request.getParameterMap().
• Pueden ser seteados en los métodos processAction (reciben el
objeto ActionResponse) mediante el siguiente método:
 Para remover un parámetro se realiza también desde el

ActionResponse:
 O también con:
portletURL.removePublicRenderParameter(name)
Portlets
 Método 2: Eventos
• Utiliza un patrón Producer-Listener
 Un portlet genera un evento
 Cero o más portlets pueden estar escuchando y reaccionar
ante el evento
• Eventos permiten la comunicación entre portlets de
diferentes aplicaciones
• Los portlets pueden publicar eventos desde processAction
usando el método: actionResponse.setEvent(event,
eventPayLoad)
• Publicar un evento causa una o más invocaciones del
nuevo método processEvent en el mismo u otros portlets
Portlets
• Desde la implementación del processEvent, también
pueden lanzarse nuevos eventos, usando el método:
eventResponse.setEvent(event, eventPayload)
• No se garantiza el orden de entrega de los eventos
• Para que la aplicación participe en el procesamiento
de eventos, es necesario decirle al contenedor cuales
eventos nos interesan.
• Adicionalmente necesitamos agregar el evento a
nuestro descriptor, de manera que Liferay conozca
qué portlet puede enviar el evento y qué portlet
puede recibirlo.
Portlets
• Definiendo el evento:
• En portlet.xml se debe agregar dentro del tag
<portlet-app> al final, el siguiente tag que indica el
namespace, el nombre del evento, y el tipo de dato
que irá en el payload:
Portlets
• Definiendo el sender:
• Ahora necesitamos decirle al contenedor, qué portlet
envía el evento, para esto se define el siguiente tag
dentro de la definición del portlet (tag portlet):
Portlets
• Para publicar el evento se realiza de la siguiente manera dentro de un
método processAction:
Portlets
 Para escuchar el evento en un portlet, se debe crear un método de la
siguiente manera:
Portlets
 Ejercicio: Creación de dos Portlets que se comunican

utilizando IPC
• Mediante dos portlets , simular el proceso de
transporte hacia al espacio de algún elemento
• La idea es solo mostrar como se envía un evento con
datos a otro portlet, para que éste ultimo realice una
acción al recibirlo
Portlets

• Crear proyecto de tipo Liferay Plugin Project
• Nombre del proyecto: ipc-beam-me-up
• Crear Portlet BeamMeUpPortlet con framework
Liferay MVC, y superclase
javax.portlet.GenericPortlet. Dejar lo demás por
defecto
• Crear Portlet ArrivalPortlet con framework Liferay
MVC, y superclase javax.portlet.GenericPortlet. Dejar
lo demás por defecto
Portlets

• Editar el archivo portlet.xml (tab Overview):
 Namespace URI: http://liferay.com/events
 Local Part: ipc.beammeup
 Value Type: java.lang.String
• En el mismo archivo, utilizar la sección Inter Portlet
Communication del portlet beam-me-up-portlet, para seleccionar
la opción «Supported Publishing Event», y seleccionar el evento
correspondiente
• En el mismo archivo, utilizar la sección Inter Portlet
Communication del portlet arrival-portlet, para seleccionar la
opción «Supported Processing Event», y seleccionar el evento
correspondiente
• Utilizar los snippets de PortalDev-02-IPC Exercise
Portlets
Portlets y WebApp Frameworks
 Los frameworks principales son:

• Struts
• JSF
• Spring Portlet MVC
• Liferay MVC es más simple de utilizar, pero es menos
estándar
Portlets
 Liferay MVC Portlet:

• ¿Porqué Liferay creó otro framework si existían los
otros?
 Baja curva de aprendizaje, y liviano
 No posee complicados XMLs de configuración
 Liferay MVCPortlet extiende LiferayPortlet, el cual a su
vez extiende GenericPortlet, con el cual estamos
familiarizados
 Extendiendo MVCPortlet tenemos acceso a todas las
capas de funcionalidad de bajo nivel en forma directa
Portlets
 Liferay MVC Portlet:

 Liferay MVC Portlet está diseñado para remover el código
repetitivo que vemos cuando se extiende GenericPortlet
 Debido a que Liferay MVCPortlet extiende LiferayPortlet,
también chequea el parámetro de inicialización add-process-
action-success-action
 Cuando este parámetro está seteado en true (por defecto), y el
método processAction se completa sin error, el portlet despliega
el siguiente mensaje:
Your request completed succesfully
Importante: Liferay MVC podría no ser la elección correcta para

todas las situaciones, se deben evaluar los diferentes frameworks
dependiendo de las necesidades.
Portlets
Ejemplo de Aplicación Funcional
 Crearemos una mini aplicación para describir

conceptos clave en el desarrollo en Liferay.
• La aplicación consiste en manejar un inventario de
piezas de naves espaciales, y sus fabricantes
• La aplicación completa consistirá de dos portlets:
• Manufacturer Portlet: Usado para agregar, editar,
eliminar y visualizar fabricantes.
• Parts Portlet: Utilizado para agregar, editar, eliminar y
visualizar partes o piezas.
• Los portlets serán no-instanciables, por lo que se
podrán agregar sólo una vez a una página.
Portlets
 Utilizaremos un enfoque MVC

 El Modelo
• Almacena y mantiene los datos, además mantiene lógica de
negocio para manipular los datos
 La Vista
• Contiene la lógica para desplegar los datos a los usuarios, en el
ejemplo utilizamos páginas JSP
 El Controlador
• Esta capa pasa datos entre las capas de view y model
• Generalmente view y model hablan solamente con la capa del
controlador
• En algunos casos, la capa view puede hablar directamente con el
modelo para propósitos de despliegue
• En el ejemplo, la clase del portlet actúa como controlador
Portlets
 Crear el proyecto: parts-inventory

Portlets
 Crear el portlet: Manufacturer Portlet

Portlets
 Crear el portlet: Manufacturer Portlet

Portlets
 Crear el portlet: Parts Portlet

Portlets
 Crear el portlet: Parts Portlet

Portlets
 Service Layer
• Liferay posee una herramienta de generación de código
llamada Liferay’s Service Builder
• Liferay posee un robusto set de servicios
• Los portlets son consumidores de estos servicios
• Los servicios pueden ser locales o remotos
• Los servicios locales son expuestos como API a clientes
ejecutándose en la misma JVM
• Los servicios remotos son expuestos como Web Services a
clientes fuera de la JVM del portal o en una máquina
remota
• Nota: Las tablas del servicio se crean al momento de
deployar el plugin
Portlets
 Liferay Service Builder

• Los servicios son automáticamente construidos por
un generador de código llamado Service Builder
• Las entidades de los servicios son modeladas en un
XML llamado WEB-INF/service.xml
• Creación: Botón derecho en el proyecto de servicio >
New > Liferay Service Builder
• Service Builder puede ser configurado en plugins de
tipo Hook o Portlet
• El generador de código del Service Builder es
invocado utilizando la tarea Ant: build-service
Portlets

• Creación de servicios:
Portlets

Portlets

Portlets

• Es posible definir columnas localizadas seteando el
atributo localized=“true” en el tag <column …/> de la
columna a localizar
Portlets

• Agregar los snippets 01-First Entity y 02-Second Entity
de PortalDev-03-Service Builder, al archivo WEB-
INF/service.xml
Portlets

• Otras configuraciones:
Portlets

• Ejecutar Service Builder:
• Importante: Debe estar configurado JDK 1.7 para el proyecto

Portlets

 Cuando se ejecuta el Service Builder, se generan
interfaces e implementaciones de los servicios
configurados. Las interfaces y clases que no deben
ser editadas, quedan disponibles en un jar para su
utilización:
Portlets
 Detalle de las clases generadas:
Portlets
 El Service Builder también genera el SQL que será
usado para crear las tablas en la base de datos:
Portlets
 Implementación de lógica de negocio:
• La capa de servicios generada, tiene operaciones CRUD por defecto
• Es posible agregar nuevos métodos, modificando las clases de
implementación, y al ejecutar el Build Service las interfaces son regeneradas:
Portlets
• Las clases Impl las genera con esta documentación de
alerta:
• Importante: El comentario anterior indica que nunca

debemos llamar a la implementación directamente, en su
lugar debemos utilizar el objeto de tipo
ManufacturerLocalServiceUtil.java
Portlets
• Agregar el contenido del snippet 03-
ManufacturerLocalServiceImpl a la clase
ManufacturerLocalServiceImpl.java, y organizar los
imports.
• Agregar el contenido del snippet 04-
PartLocalServiceImpl a la clase
PartLocalServiceImpl.java, y organizar los imports.
• Una vez modificadas las implementaciones,
ejecutamos el Service Builder para que regenere las
interfaces respectivas.
Portlets
• Liferay es agnóstico de la base de datos, y provee un
método agnóstico para generar claves primarias para
registros de base de datos.
• Se utiliza el servicio increment de la clase
CounterLocalService de la siguiente manera:
Portlets
• En el ejemplo anterior counterLocalService es una
referencia a una instancia de CounterLocalServiceImpl, el
cual es inyectado por el Service Builder (mediante Spring)
en la implementación que la está utilizando
• Esta referencia es heredada de
ManufacturerLocalServiceBaseImpl junto a otros objetos
más inyectados (no se debe modificar esta clase).
• También podríamos haber utilizado la clase
CounterLocalServiceUtil para llamar al servicio y obtener el
id incrementado (pero no es lo óptimo):
Portlets
 Inyección de Servicios:
• Hay tres servicios que son inyectados automáticamente
por el Service Builder en la clase generada
xxxLocalServiceImpl:
 CounterLocalService: Utilizado para manipular IDs de assets
generados
 ResourceLocalService: Provee métodos relacionados a la
creación, actualización y eliminación de nuevos assets
 UserLocalService: Provee métodos relacionados a la creación
y eliminación de nuevos usuarios, como así también la
administración de su información
• Importante: Estos servicios proveen métodos vitales para
la integración con assets, usuarios y permisos en Liferay

Liferay 6.2: Desarrollo de Plugins (Parte 1)

Uploaded by

Copyright:

Available Formats

You might also like

Liferay 6.2: Desarrollo de Plugins (Parte 1)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Liferay 6.2: Desarrollo de Plugins (Parte 1)

Uploaded by

Copyright:

Available Formats

Liferay 6.

 Los portlets desarrollados en el plugin SDK solamente pueden

 Los portlets pueden hacer uso de cualquier framework de

 JSR-168 -> Especificación de la versión 1.0 de portlets,

 JSR-286 -> En la segunda versión de portlets, se agregaron

processEvent() -> (JSR-286) Llamado cuando un evento ha sido gatillado

 Por lo tanto, los portlets poseen más de un tipo de

• Llamado por el contenedor durante el despliegue del portlet

• En esta fase el portlet genera contenido basado en su

• Los portlets típicamente ingresan a la fase Render cuando se recarga la

 <a href=”<portlet:renderURL/>”>Click to invoke Render Phase</a>

• Se ingresa a esta fase como resultado de la interacción de

 Los portlets ingresan a la Action Phase mediante la

 <a href="<portlet:actionURL/>">Click to invoke

• Fase utilizada para procesar cualquier evento que haya

 RESOURCE SERVING PHASE:

• Esta fase permite a los portlets servir contenido

 RESOURCE SERVING PHASE:

 RESOURCE SERVING PHASE:

 RESOURCE SERVING PHASE:

• El método destroy() es llamado por el contenedor de

• Estos archivos son opcionales, y permiten

 Ejercicio: Creación de Portlet Básico

 Ejercicio, pasos a seguir:

 Es importante eliminar el método “processAction”, ya que si está presente

 Es introducido en Portlet 2.0 (JSR-286), y define dos

 Método 1: Public Render Parameters

 Método 1: Public Render Parameters

• Pueden obtenerse utilizando el siguiente Map:

 Método 1: Public Render Parameters

 Para remover un parámetro se realiza también desde el

 Ejercicio: Creación de dos Portlets que se comunican

 Ejercicio, pasos a seguir:

 Ejercicio, pasos a seguir:

 Los frameworks principales son:

 Liferay MVC Portlet:

 Liferay MVC Portlet:

Your request completed succesfully

Importante: Liferay MVC podría no ser la elección correcta para

 Crearemos una mini aplicación para describir

 Utilizaremos un enfoque MVC

 Crear el proyecto: parts-inventory

 Crear el portlet: Manufacturer Portlet

 Crear el portlet: Manufacturer Portlet

 Crear el portlet: Parts Portlet

 Crear el portlet: Parts Portlet

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

 Liferay Service Builder

• Importante: Debe estar configurado JDK 1.7 para el proyecto

 Liferay Service Builder

• Importante: El comentario anterior indica que nunca

You might also like