Perso, pour faire un site accessible, les portails NE me semblent PAS apporter un plus.

Par ex, cf. le point 14 du WCAG1.0 : « S’assurer que les pages sont claires et simples »

Les pages web d’un portail avec pleins de boites à l’intérieur, cela me semble aller à l’encontre de ce point du WCAG1.0. Et cela me semble occasionner aussi de possibles difficultés de lecture.

Note : par ailleurs, WCAG2.0 ne bannit plus JS du poste client.

@MikaFromParis

Je ne vois pas franchement un portail comme un framework de standardisation des services comme authentification, profils, navigation, look n feel…

Ces services sont généralement standardisés en dehors d’un portail (à travers, par ex, un serveur d’identité pour l’authentification et les profils) et un portail se contente d’intégrer /d’utiliser ces services.

Un portail, c’est surtout une affaire d’intégration. Et de ce point de vue, je ne vois pas tellement ce qu’un portail apporte de plus qu’une approche qui serait basée sur GWT (cf. mes arguments plus haut, dans précédents posts).

Ok les portails d’appli apportent une certaines « lourdeur », mais un peu comme tout ce qui donne un cadre : il faut s’y conformer…

Ils ont cependant le grand avantage de standardiser des aspects qui, dans les entreprises, sont souvent traitées de facon complètement hétérogène de projet en projet : authentification, profils, navigation, look n feel…

Pour moi, je vois un peu le portail comme un framework de standardisation de ces services.

Après, biensur, on peut toujours tout faire en GWT, en Wicket en ce qu’on veut…dans le monde JEE, tout est toujours possible de 1000 facons, toutes plus intelligentes et killer les unes que les autres. Mais si on se place au niveau de l’entreprise, il me semble interessant d’adoptier une démarche qui donne un cadre a des services techniques qui sont souvent consommateurs de temps et donc de budget alors qu’ils ne devraient plus l’etre…

Les portails ne sont pas morts. Loin de là. Vous oubliez la nécessité pour les sites privés, voire l’obligation pour les sites publiques d’être accessibles. Les gadgets/widgets sont donc mis a mal car ils nécessitent la présence du javascript. Or, un site accessible a pour principale contrainte de devoir fonctionner sans javascript.
Enfin, la nécessité pour les sites commerciaux d’avoir une réactivité accrue impose l’utilisation d’un CMS (maison ou commercial) en plus de la solution eCommerce utilisée. Le portail sert donc souvent d’intégrateur graphique. Liferay, s’il avait un meilleur CMS serait une solution vraiment intéressante. Malheureusement pour les intégriste du java, aujourd’hui, les meilleurs CMS font partie du monde PHP.

J’aime bien la fin de ta prose : « Néanmoins, l’essor des framework type GWT, risquent à terme de remettre en cause le modèle du portail. »

Par ailleurs, un sympathique commentateur de mon blog m’a indiqué qu’il avait créé (depuis un certain temps déjà) des portlets-like mais à la sauce GWT :
« We had a the same idea a little while ago and it resulted in ‘GWT Portlets’:

http://code.google.com/p/gwtportlets/

GWT Portlets is a free open source web framework for building GWT (Google Web Toolkit) applications. It defines a very simple & productive, yet powerful programming model to build good looking, modular GWT applications. The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The « portal » is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider. »

Comme quoi, je ne suis pas seul à penser que GWT ressemble fort au futur des portlets…

GWT aujourd’hui est une API web qui sert pour faire des applications riches, avec un maximum de traitement du coté client (Web as a a platform). Et qui di GWT dit programmation.

Le premier objectif du portail était d’éviter de programmer le plus possible. Ensuite, entre un portail e-commerce (type magento), un intranet, un portail de collaboration et un portail d’infrastructure, rien n’est comparable.

Le portail d’infrastructure, type liferay ou GateIn, contrôle de manière plus forte les interactions entre le client et les applications du coté serveurs. C’est un outil d’intégration au niveau de l’interface graphique. On peut y intégrer les portlets, les widgets, les gadgets, etc.

Le portail d’infrastructure est aussi utilisé pour son modèle de gestion des rôles et de la sécurité. De même, si tu utilises Alfresco, alors tu perds l’intérêt du portail, car la sécurité n’est plus unifiée avec le portail. D’où l’intérêt de prendre le CMS du portail.

Enfin, le portail n’est pas vu par les financiers qui gouvernent le monde comme une application. Donc de plus en plus, les entreprises vont chercher a outsourcer leurs portails (quitte meme a utiliser Netvibes). Pour convaincre le management de réécrire une application qui ressemble à un portail en GWT, je vous souhaite bon courage.

Néanmoins, l’essor des framework type GWT, risquent à terme de remettre en cause le modèle du portail. Il faut juste que quelqu’un s’amuse à intégrer le meilleur des deux mondes!

Le mashup, le push de données (via comet), la gestion multi-canal et la communication inter « fenetres » sont des besoins cruciaux.

Quel est l’avantage pour les portlets d’être normalisées ?
Oui, CORBA aussi est normalisé, et alors ?
Quelques fois la normalisation, c’est un pansement sur une jambe de bois…

Quant à l’échange entre composants GWT à coup d’évènements uniquement coté client, j’en doute.
Soit une portlet/composant GWT p1 associée au service (coté serveur) s1
idem pour p2/s2.
AFAIK, avec GWT, rien n’empêche p1 d’appeler le service s2 (=> échange de msg entre portlets réalisé du côté serveur).
Autre ex : rien n’empêche p1 d’appeler un service de notification coté serveur pour transmettre un msg aux observateurs (comme s2).

Mais revenons à la discussion générale.

Dire « JSF va-t-il remplacer Hibernate la semaine prochaine… » pour indiquer que GWT ne peut pas remplacer les portlets, c’est un peu fort de café…
JSF et Hibernate opèrent dans des couches différentes,
tandis que les portlets et GWT opèrent dans les mêmes couches…

portail != conteneur de portlets
Mais les portlets ont gravé dans le marbre des API la notion de portail.
Ceci étant, les portails, IMHO, ce ne sont pas que des API, c’est aussi un design, une archi.
Les portlets incitent à penser que la bataille des portails se jouent sur le champ des API, moi, je pense que l’on n’est pas forcément obligé de passer par ces fourches caudines-là et que l’on peut définir un portail autrement, en respectant le design, l’archi d’un portail.

Bref, pour moi, le champ de bataille ‘portail’ avec GWT et les portlets, c’est un peu: « l’esprit (design/archi) et la lettre (= ce qu’est un portail gravé dans le marbre des API) ».

Autrement dit, oui, GWT ne fournit pas un portail (clé en main avec les « bonnes » API),
Ceci étant, GWT est capable d’en respecter le design/l’archi .
Donc, les portlets et GWT ont bien à voir l’un avec l’autre.

Bien sûr, GWT reste un framework web, mais s’il y a un framework web capable de secouer le cocotier des portails (vu uniquement comme conteneurs de portlets), c’est bien IMHO GWT.
Pour différentes raisons, par ex, par la taille de la communauté GWT, par son évolution rapide, et aussi coté technique, par le fait que les composants GWT sont à cheval entre la partie cliente et la partie serveur, exactement comme les portlets !

Je pense que tu mélanges les deux concepts, et je ne suis pas d’accord lorsque tu dis que l’un peut remplacer l’autre… car ils n’ont rien à voir. GWT est une technologie de rendu Web. Ce n’est pas une spécification normalisée avec différents éditeurs. C’est un moyen pour que les développeurs Java arrivent à utiliser le paradigme de la programmation à la Swing et génère des interfaces riches en HTML+CSS+JS.
Le principe d’un Portail d’intégration tel que Gartner le décrit, est de proposer un moteur d’exécution de Portlets. Tu peux tout à fait écrire des Portlets avec GWT, avec Wicket, avec Tapestry, avec JSP simple, avec ce que tu veux… Le portail se propose de regrouper des services d’infrastructure comme l’authentification. GWT ne supporte pas tout ce qui est SSO comme un Liferay qui fait du CAS, du SiteMinder par exemple… tout simplement car cela n’a rien à voir.

Cela me rappelle le client chez qui j’ai travaillé, qui a développé son portail en GWT. Oui super, en effet nous avons des boites qui se mettent cote à cote, ce qui laisse croire que GWT peut faire ce que fait un conteneur de Portlet…. mais c’est faux. L’échange des événements est fait en Javascript du côté du client pour GWT là où merci les Portlets, les échanges de message entre portlets sont fait du côté serveur.

Et que l’on ne me fasse pas dire que je n’aime pas GWT, je remets à sa place GWT là où il doit être, et je suis vraiment pas d’accord avec ton idée de GWT vs Portail d’intégration, car cela n’a rien à voir.

On peut faire aussi Wicket peut-il remplacer les serveurs Webs et ensuite JSF va-t-il remplacer Hibernate la semaine prochaine….

«  »Jette un oeil sur l’étude Gartner, qui parle des portails horizontaux type Liferay et des perspectives. C’est pas si délirant. »"
=> comme je l’ai indiqué plus haut, je me demande s’il n’y a pas confusion dans l’esprit de Gartner entre portail et suite d’applis collaborative. Quoiqu’il en soit, je doute de cette étude Gartner: autour de moi, je ne vois AUCUN projet utilisant un portail ! Et cela fait longtemps que je n’ai pas vu de nouveaux projets utilisant un portail… En fait, les personnes autour de moi ne proposent JAMAIS de portails, sauf s’il y a une forte demande du client.

«  »Je ne vois pas ce que GWT vient faire ici… C’est une technologie de rendu web. Un portail d’intégration fournit des services comme l’authentification, l’hébergement de portlets, l’échange de messages, la mise en page… »"
=>
Peut être que j’aurais du plus rentrer dans les détails…
(1) authentification : peut être défini avec un filtre de servlet, donc, c’est pas spécifique aux portlets, et donc, cela peut être réalisé avec GWT
(2) hébergement de portlets ~ en gros, c’est du packaging, sauf que, comme je l’ai indiqué dans mon post, il manque sans doute encore à GWT une certaine modularité pour faire du hot deploy de nouvelles portlets (hot deploy coté serveur), mais bon, cela n’est pas pour moi un point critique-critique.
(3) échange de message : AFAIK, on peut coder avec GWT des échanges de message coté client, entre composant coté client, et coté serveur, IMHO, c’est de l’échange de messages classiques genre SOA.
(4) la mise en page, c’est aussi le domaine de GWT (cf. par ex, le composant de Ext JS).

Donc, en résumé :
- GWT permet d’offrir les fonctionnalités (1), (2) et (4) des portlets, ou dit autrement, GWT offre une bonne partie de ces fonctionnalités.
- GWT ne permet pas (encore ?) d’offrir la fonctionnalité (3) que je juge pas super critique.

Bref, pour moi, GWT est sur le terrain des portlets, et gagne du terrain !

«  »Les gens d’eXo font aussi conteneur de Gadget OpenSocial. Ils peuvent afficher sans problèmes des Gadgets de Google… écrit en GWT. »"
=> en gros, comme GWT produit du HTML+JS, cela signifie que dans une page eXo, on peut inclure du HTML+JS – bon, ok.
Vu le peu d’info ici sur ce point, je dirais qu’ils utilisent GWT pour définir un composant unitaire, ce qui est (tjrs) possible, car on peut inclure un fragment HTML+JS dans une page web.
Mais je ne crois pas qu’ils utilisent GWT pour (re)définir une archi portlet-like à la sauce GWT, en utilisant toute la puissance de GWT.

Donc, cela reste des portlets avec un peu de GWT si nécessaire. Et si, comme je le crois, GWT, tout seul, apporte une solution proche des portlets, a une plus grosse commauté que les portlets, ouvre plus de portes que les portlets, etc. alors on retrouve sur un même bateau 2 technos qui cohabitent et qui pourraient faire le job chacune toute seule de son coté. Il risque d’y avoir un mort, quelqu’un va finir par tomber à l’eau, et je ne crois pas que le mort, le noyé, ce soit GWT !

«  »Non je n’ai pas compris pourquoi tu parles de GWT ici, pour moi cela n’a rien à voir. »"
=> J’espère avoir été plus clair.
Tu me fait penser qu’il faudrait que j’écrive sans doute un nouveau post dans mon blog pour être plus clair

Jette un oeil sur l’étude Gartner, qui parle des portails horizontaux type Liferay et des perspectives. C’est pas si délirant.

Je ne vois pas ce que GWT vient faire ici… C’est une technologie de rendu web. Un portail d’intégration fournit des services comme l’authentification, l’hébergement de portlets, l’échange de messages, la mise en page…
Les gens d’eXo font aussi conteneur de Gadget OpenSocial. Ils peuvent afficher sans problèmes des Gadgets de Google… écrit en GWT.

Non je n’ai pas compris pourquoi tu parles de GWT ici, pour moi cela n’a rien à voir.

Mais sinon ton article est intéressant, je suis allé le lire

Nicolas