Vers la fin de l’environnement d’extension?

Introduit avec la version 4.3.1 de Liferay, le plugin SDK de Liferay n’a eu de cesse d’améliorer jusqu’à se placer, avec sa version 5.1, en véritable concurrent de l’environnement d’extension. Pour rappel, Liferay propose 2 méthodes de développement :

  • L’environnement d’extension, la méthode historique qui permet une customisation et une surcharge pousée du portail ainsi que le développement de portlets.
  • Le plugin SDK, introduit avec la version 4.3.1 de Liferay, qui avait pour objectif de proposer un outillage léger pour le développement de portlets et de thèmes Liferay.

Si les cibles étaient bien définies entre les 2 méthodes, les versions 5.0.1 (sortie uniquement en RC) et 5.1 changent la donne. Dorénavant, le SDK de Liferay se voit attribuer de nouvelles fonctionnalités :

  • Disponibilité du ServiceBuilder pour un développement de la couche métier des portlets via une approche MDA.
  • Introduction d’un nouveau type de plugin : les hooks.

Les fonctionnalités jusqu’alors disponible à partir du SDK rentraient tout à fait dans le cadre d’un outillage pour le développement avec Liferay, mais les hooks vont encore plus loin et offrent maintenant des possibilités de surcharge des fonctionnalités du portail, un domaine jusqu’alors réservé à l’environnement d’extension… Grâce aux hooks, il est ainsi possible de  :

  • surcharger le portal.properties
  • d’enregistrer des listeners sur les objects Liferay : UserListener, GroupListener, …
  • d’enrichir les évènements disponibles : ServicePreAction ou StartupAction par exemple

Je ne peux que saluer cette introduction qui permet une simplification du mode de développement, l’environnement d’extension, plus lourd, devenant le dernier recours pour les cas particuliers (surcharge des portlets par défaut par exemple).

Un exemple d’utilisation

La portlet World Of Liferay est un bon cas d’utilisation du mécanisme de hook (c’est d’ailleurs sans doute elle qui a servi de test grandeur nature à l’introduction des hooks) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 5.1.0//EN" "http://www.liferay.com/dtd/liferay-hook_5_1_0.dtd">

<hook>
	<event>
		<event-class>com.liferay.wol.hook.events.StartupAction</event-class>
		<event-type>application.startup.events</event-type>
	</event>
	<event>
		<event-class>com.liferay.wol.hook.events.LoginPostAction</event-class>
		<event-type>login.events.post</event-type>
	</event>
	<model-listener>
		<model-listener-class>com.liferay.wol.hook.listeners.GroupListener</model-listener-class>
		<model-name>com.liferay.portal.model.Group</model-name>
	</model-listener>
	<model-listener>
		<model-listener-class>com.liferay.wol.hook.listeners.UserListener</model-listener-class>
		<model-name>com.liferay.portal.model.User</model-name>
	</model-listener>
	<portal-properties>portal.properties</portal-properties>
</hook>

L’exemple est intéressant car il couvre la plupart des fonctionnalités introduites via les hooks :

  • L’ajout de listeners sur les objets Liferay com.liferay.portal.model.User et com.liferay.portal.model.Group. Cela permet à notre plugin Liferay d’exécuter du code en fonction du cycle de vie des objets référencés (avant et après création, avant et après mise à jour et avant et après suppression). Si les listeners sont liés forcément à des objets issues du mécanisme de création de service Liferay (le ServiceBuilder), les classes s’abonnant à ces listeners doivent uniquement implémenter l’interface com.liferay.portal.model.ModelListener.
  • Une surcharge de la configuration du portail via l’utilisation du fichier portal.properties.
  • Un enregistrement de nouvelles actions, com.liferay.wol.hook.events.StartupAction et com.liferay.wol.hook.events.LoginPostAction implémentant toutes les 2 com.liferay.portal.struts.SimpleAction et étant exécutées par le portail respectivement après le lancement du portail (ou pour être plus précis pour chaque lancement de VirtualHost, Liferay offrant des fonctionnalités de Virtual Hosting par compagnie) et après connexion utilisateur. Il faut noter que ces actions s’ajoutent à la liste d’action existante et ne redéfinissent en aucun cas les valeurs par défaut (fichier portal.properties et portal-ext.properties).
Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*