C’est exactement ce genre de détail qui m’énerve avec jsf. On peut faire facilement et en fin de compte assez proprement des belles applications web assez puissantes. L’intégration avec Ajax (jsf2, mais ça vient de jsf 1.2+facelets+richfaces) est vraiment superbe.
Mais la sélection d’un bidule dans une liste…
En fait c’est lié à quelque chose dont tu ne parles pas (bizarrement!. JSF est statefull et Play est stateless. D’après ce que j’ai compris, Jsf fait correspondre une liste en mémoire avec un événement généré (clic sur un bouton etc…) par l’IHM . Donc il doit garder la liste en session, donc garder une façon de choisir dans la liste (DataModel) . Alors qu’en html stateless, on passe l’ID et l’objet sera rechargé.
J’ai passé pas mal de temps au début à essayer de passer des paramètres en jsf. Or, il y a des comportements différents dans le passage de paramètre entre deux manières de faire des liens (je ne me souviens plus le détail mais en gros dans un cas le paramètre était récupérable et dans l’autre pas) J’ai commencé à maîtriser la sélection d’un item dans une liste quand j’ai laissé jsf le faire à ma place avec un datamodel. Quand on connait html, http, quand le mot « stateless » a du sens pour soi, et ben ça énerve grave… Et puis après on s’y fait!

A mon sens, on peut faire bien plus de chose en écrivant le HTML à la main, sans pour autant y passer plus de temps (voir même moins).
Par exemple, faire un système d’onglet, avec jQuery, « $(‘#onglets’).tabs() », ça ne me parait pas plus long qu’avec JSF, et le code sera lisible par n’importe qui, sans avoir à faire 3 semaines de formation JSF.

« datatables paginées » => La c’est exactement ce que j’appel un composant sur-complexe, faire un liste paginée, même seulement avec des servlets / JSP c’est pas bien compliqué, avec Play! c’est presque trivial.
En utilisant les composants par default JSF (ou asp.net, ne soyons pas raciste, j’ai touché aux deux) ça deviens soudainement complexe…

Attention, je ne suis pas en train de dire, « JSF caylemal » (même si pour le coup, je suis pas fan) ou « Les frameworks web orienté composant sapu »
Je pense que le principale intérêt de cette approche est la possibilité de partager des bibliothèques au sein d’une (grosse) entreprise. L’équipe A développe des composants spécialement pour la société, et les équipe B, C, et D peuvent les utiliser sans trop se poser de questions.

Le principale reproche que je ferait à JSF dans les vue, c’est que parfois (voir souvent), comme dans l’exemple de Nicolas, le code deviens tres tres moche sans pour autant en tiré de la valeur ajoutée.

ex:

[...] qui n’apporte rien du tout par rapport à une « bete » table HTML.

@jto
Effectivement on peut toujours faire une interface riche en HTML et Javascript(jQuery) en codant à la mimine. Ce qu’on faisait finalement quand on faisait du Struts qui ne propose pas de composants d’IHM tout fait.

Je crois que la force de JSF n’est pas dans les bibliothèques de composants « sur-complexe » mais au contraire dans les composants classiques mais néanmoins difficiles à gérer en HTML (surtout si y a une pointe d’Ajax): système d’onglets, popup, captcha, menu contextuels, datatables paginées…

Nous utilisons en ce moments pas mal de composants PrimeFaces parce qu’ils sont simples à intégrer et on gagne pas mal de temps.

Alors certes, JSF apporte des composant prêt à l’emploi, mais les possibilités au final sont les même si tu maitrise un peu HTML et jQuery.

De toute manière, quoi qu’il arrive, il me parait utopique de penser qu’avec JSF on va juste utiliser des composants, sans jamais mettre les mains dans le cambouis et coder ses propres bibliothèques.

Le mécanisme de tags de Play! permet de faire plus ou moins la même chose. La « richesse » des interfaces est la même quelque soit le framework, c’est juste le moyens d’y arriver qui diffèrent. D’ailleurs si un fwk web t’impose des limites en termes d’IHM, c’est qu’il y’a un gros GROS problème.

Personnellement je préfère écrire du bon vieux HTML et un peu de JS plutôt que de devoir me palucher les docs de composants sur-complexes, pour arriver à quelque chose de décevant. Évidement tout cela dépend du contexte, mais en général, écrire directement du HTML, ça fonctionne.

Bon, un peu gros mon troll, je crois que je n’arriverai pas à lancer un débat rageux .

J’aime bien ton introduction en forme de « prenez du recul ». C’est une approche qu’il faut avoir dès qu’on réalise des comparaisons techniques .