article de presse - Cap Data Consulting

T echnologie
requêtes sur "deux événements". La classe
principale est évidemment le controller
PortletServlet qui hérite de ActionServlet. La
gestion du premier événement est déléguée
aux actions Struts et celle du deuxième événement
pour le rendu est traitée par les pages
JSP à la sortie des actions. Une application
Struts développée selon les standards préconisés
peut être déployée comme un portlet
avec très peu de modifications (modification
des descripteurs, ajout du portlet.xml, ajout de
librairies, remplacement des tags Struts par les
tags Struts Bridge). Il est ensuite encore possible
de déployer l'application adaptée à un
environnement portlet comme une application
Web standard, ce qui peut faciliter et accélérer
les phases de développement et de test.
Aller plus loin ?
Dans le cadre de la rédaction de cet article,
d'autres aspects relatifs aux portlets ont été
explorés. Cela inclut notamment le développement
d'un deuxième portlet plus complexe.
Ce portlet gère des actions de l'utilisateur.
Il affiche toujours la date et l'heure
courantes, mais cette fois-ci, l'utilisateur
peut sélectionner le fuseau horaire à utiliser
pour l'affichage. Les modes 'help' et 'edit'
sont implémentés pour afficher un message
d'aide et pour sélectionner le format d'affichage
parmi une liste prédéfinie. Les services
permettant de sauvegarder des préférences
de l'utilisateur sont utilisés pour
conserver le format d'affichage entre plusieurs
sessions.
Ce portlet utilise des pages JSP pour générer
les vues. Ces JSP permettent d'extraire le code
HTML du portlet, ce qui rend l'écriture des
pages beaucoup plus aisée. Le portlet se comporte
alors comme un controller qui traite les
requêtes de l'utilisateur et qui sélectionne la
vue à afficher.
Un autre axe développé concerne la compatibilité
de plusieurs portails OS et commerciaux
avec la spécification JSR-168. En effet, l'utilité
et le succès de cette spécification ne peuvent
qu'aller de pair avec un support large des portails
du marché. Les deux portlets développés
ont donc été testés sur plusieurs serveurs
commerciaux et systèmes pour vérifier leur
niveau respectif de compatibilité. Il s'est avéré
que cette dernière était très bonne car les
deux portlets de tests ont parfaitement fonctionné
sur les 7 portails suivants :
• Jetspeed 2
• Liferay Portal Pro 3.6.1
• exoPlatform 1.0
• jBoss Portal 2.0
• uPortal 2.5.0
• BEA WebLogic Portal 8.1
• IBM WebSphere Portal 5.0.2.1
Pour chaque portail, il a été nécessaire d'effectuer
une petite préparation de notre application
de test (ajout d'informations dans le
fichier web.xml, ajout de descripteurs supplémentaires).
Néanmoins, la compatibilité est
bien là et le déploiement s'effectue sans problème
particulier sur ces portails.
Cela nous montre que cette spécification est
maintenant largement supportée. Cela permet
d'envisager sereinement de développer des
portlets en l'utilisant.
Conclusion
Cette spécification a encore plusieurs limitations.
On peut noter l’absence de la notion de
filtres. Comme il existe des ServletFilter pour
filtrer des requêtes, il serait utile de pouvoir le
faire dans un portlet. Ce n’est pour l’instant
possible qu’en faisant un développement spécifique.
On trouve une autre limitation dans la
communication inter-portlets. L’API ne met
aucun outil à disposition pour transmettre des
informations entre des portlets au sein d’un
portail. Là aussi, un développement spécifique
utilisant le contexte du portail devrait permettre
de parer à cette situation, mais laisse
encore aujourd’hui la porte ouverte à des
Programmez n°85 53 avril 2006
implémentations propriétaires.
Le groupe d'experts travaillant sur cette spécification
semble vouloir adresser ces limitations
dans la version 2.0 de l’API (JSR-286). IBM a
proposé cette nouvelle version en décembre
2005 pour une revue initiale, la version finale
est prévue pour fin 2006.
En marge des améliorations déjà mentionnées,
cette version devrait normalement apporter
plusieurs nouveautés telles que :
- l'interopérabilité avec la norme CC/PP (capacités
combinées/profils de préférences) via
JSR-188. Cette norme permet à l'utilisateur de
définir les caractéristiques du terminal utilisé
pour visualiser un site ainsi que les préférences
de consultation. En fonction de ces
paramètres les portlets pourront adapter le
contenu à afficher.
- l'alignement avec la version 2.0 de WSRP.
- l'amélioration de la librairie de tags.
- le support de J2EE 1.4.
- un rapprochement entre JSF et les portlets.
Références
- La spécification :
http://www.jcp.org/en/jsr/detail?id=168
- Le site Apache relatif aux portails (Pluto,
Jetspeed…) :
http://portals.apache.org/
- Des sites d’échanges et d’informations sur
les portlets :
http://portlet-opensrc.sourceforge.net/
http://www.portletswap.org/
http://community.java.net/portlet/
http://groups.yahoo.com/group/portlets/
Pour aller plus loin :
http://www.sqli.com/sqliCorpo/home/sqli/veille
_it/breves~pid/comprendre_et_developper_de
s_portlets_en_java
■ Frédéric Chopart
Consultant du Groupe SQLI
www.programmez.com
TOUT NOUVEAU, TOUT BON !