Première présentation ce matin : « Portlet 2.0 » par Thomas Heute de JBoss/Red Hat.
La spécification des Portlets 2.0 est sortie en juin 2008. Thomas nous donne un retour un an après de la conférence. Lui-même contributeur depuis 2004 sur JBoss Portal, une année sur JBoss Seam, il est aujourd’hui le responsable du projet JBoss Portal chez RedHat.
L’agenda de sa présentation sera :
– Quelles sont les nouvelles fonctionnalités de la version Portlet 2.0
– Adoption par les vendeurs
– La portabilité
– Portlets versus Gadgets
Dans un premier temps, retour sur la JSR-286 Portlet 2.0 sortie l’an passé. Tout d’abord l’une des innovations les plus importantes est ce qu’il appelle « Resource Serving ». L’objectif est de permettre l’envoi de données vers le navigateur qui ne font pas partie du portail, comme un fichier PDF ou Excel par exemple, tout en conservant les fonctionnalités d’une portlet. Cette spécification vise donc à offrir un accès au contexte afin d’assurer le support de la sécurité et de l’accès aux données par exemple.
Il montre ensuite l’interaction entre les portlets avec une RemoteCommandPortlet sur une démonstration fonctionnant avec JBoss Portal. Une fenêtre HTML détachée permet d’envoyer des commandes à une autre portlet, la gestion de l’asynchrone est très simple.
A ce propos, il explique que les améliorations du support d’Ajax dans la spécification Portlet 2.0 permettent à des frameworks comme ICEFaces ou RichFaces de fonctionner correctement dans des portlets.
Les Portlets 2.0 peuvent maintenant partager leurs paramètres avec d’autres produits ce qui permet de faire communiquer les portlets entre elles. Thomas Heute montre l’exemple d’une portlet Google Map et d’une portlet Weather qui recoivent toutes les deux en paramètre le code postal d’une ville américaine.
Une portlet peut aussi déclencher une événement, les autres portlets peuvent être notifiées et se mettre à jour. Il conseille de ne s’en servir que pour de la mise à jour de l’interface.
Sur le slide suivant il dresse un état de l’implémentation de la spécification par les différents acteurs du marché :
La JSR-286 Portlet 2.0 est en version finale depuis le 12 juin 2008.
– JBoss Portlet Container 2.0 est sorti le 13 juin 2008 puis inclus dans JBoss Portal 2.7.0 en octobre
– eXo Portlet Container 2.0 est sorti le 18 juin 2008, mis dans eXo Portal le 1er juillet 2008
– Liferay portal a sorti sa version le 17 juillet 2008
– Apache Jetspeed assez tardivement le 27 mai 2009 dernier
– IBM Websphere portal 6.1 a été disponible sept 2008
– Oracle Portal (BEA () + Oracle (2) + Sun(1)) ?
Concernant le support des frameworks WEB il existe 2 spécifications
JSF Support:
– JSR-301 specification addresses JSR-166
– JSR-329 addressing JSR-286 (JBoss Portlet bridge on the way)
De ce qu’il a pu voir sur les forums, les pages :
Wicket support -> mostly there with support for events
Sruts 2 plugin for JSR-286
Spring MVC also support JSR-286
WebWork
A propos de la portabilité : attention la spec ne dit pas comment on fait un portail mais une portlet.
La notion de page n’est pas définie.
La communication entre portlet:
– UI Level
– Le mécanisme événementiel n’est pas un remplacement par JMS, ne pas abuser de ce mécanisme.
– Doit-on se coordonner à travers les pages ?
– Portlets aren’t a template mechanism per se
Rester à une gestion des événements entre portlet qui sont sur la même page si vous ne voulez pas avoir de soucis.
Slide suivant qui m’a fait sourire : Portlet vs Widget vs Gadget (vs Toilet ?)
Thomas Heute explique tout d’abord en quoi consiste un Gadget, tel que l’on peut le voir sur Facebook. C’est un affichage déporté dans un autre site web d’une fonctionnalité hébergée sur un serveur primaire. Une portlet est plutôt la représentation locale d’un service distant, c’est une composition gérée par un portail, afin d’assurer des services communs (authentification, autorisation, communication, etc) dans un seul endroit.
Il cite différentes initiatives autour des Gadgets :
Google OpenSocial, OpenAjax Alliance (OBM, Google, Sun, Red Hat, Oracle, Microsoft) -> Widget proposal
L’avantage des Portlets par rapport à un Gadget/Widget:
-> Fait pour des applications plutôt complexes.
-> Vous pouvez utiliser votre framework en général,
-> L’état des portlets est gardé lorsque la page se rafraichie.
-> propagation de l’identité, de la sécurité, interaction avec un portail, visuel.
Les gadgets ont l’avantage d’être développable rapidement, comme pour consommer par exemple un flux RSS. Facile pour l’intégration du côté client, facile pour partager de l’information. On pense au Gadget Twitter que j’ai sur mon blog par exemple.
Il termine par un slide sur ses idées pour l’avenir
> We could use more annotations a la Servlet 3.0 or JSF 2.0 @Portlet (no portlet,xml)
> We could all benefit from a PORTAL specification
– more aware of the environment, communication with the portal itself
– Portal object management
– Federated search/index
Enfin il revient sur l’annonce du parternariat entre JBoss Portal et eXo Portal. Il résume cela par
« JBoss builds the platform, eXo Platform builds the solution, We are hiring ! »
Réflexions et conclusion
Présentation intéressante, je crois que les Portlets 1.0 ne doivent plus être utilisées. Je travaillerai cet été à l’étude de différents portails pour le client avec lequel je travaille, le sujet est donc d’actualité. Mon souci du moment : comment proposer l’étude d’alternative à la politique d’achat qui voudrait que l’on prenne Oracle Portal, sans savoir si celui-ci correspond à nos besoins ? Mais c’est une autre histoire…
