Discussion :

[PanzerKunst]

Ok merci. A ce propos, si j'avais à l'heure actuelle l'occasion de faire un site Wicket avec base de données, j'utiliserais certainement Databinder (Hibernate pour Wicket), ca semble puissant

[slevy]

Perso je trouve 2 avantages majeurs à JSF :
- le richesse des bibliothèques de composants
- le fait que ce soit le standard (par exemple le framework Seam se base sur JSF pour adresser l'intégration avec les EJB3)

[el muchacho]

Aux frameworks web pour Java généralement considérés comme bons (je ne compte pas Grails qui n'est pas du Java):
- Wicket
- Tapestry 5
- Jboss Seam

je rajouterai Stripes, qui est sans doute le meilleur choix pour ceux qui viennent de Struts, et est l'un des frameworks web les plus sous-estimé. Très simple d'approche, nettement plus performant et agréable que Struts2, ce framework MVC réduit la configuration par XML à zéro grâce à l'utilisation de conventions de nommage et des annotations (à l'instar de Tapestry).
Contrairement à Tapestry qui a une certaine réputation de complexité, il n'y a pas de "magie" derrière et il peut être rapidement appréhendé par des développeurs débutants. C'est typiquement le framework pour lequel il est facile d'évaluer les temps de développement parce qu'il ne posera pas de (mauvaise) surprise.
Chose rarissime, absolument tous les retours d'expérience que j'ai pu lire sur ce framework sont positifs.

Et enfin, pour les applications riches, on a le choix entre echo3, Flex, GWT, OpenLaszlo (le site marchand de la Fnac et de WallMart sont faits avec) et Zk.
http://blog.xebia.fr/2008/10/03/ria-...-echo3-javafx/

[nicorama]

Autre : ExtJS

Mais paramétré avec JSP; par exemple dans /home.jsp, en pseudocode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
<robusta:authentication/> <%--  definit les variables ${user}, ${idUser}, ${idSchool} --%>
<script>
 
Ext.onReady{
 
  <c:if ${user.isTeacher}>
     showPanelTeacher();
  </c:if>
 
}
 
</script>

C'est un peu experimental, trouvé dans le train ce week-end. J'en saurais plus dans une semaine.

[djo.mos]

C'est vrai qu'avec ExtJS le rendu est époustouflant, mais franchement, au vu du code que ça nécessite, ça n'en vaut pas la peine : l'un des buts fondateurs de la majorité des frameworks MVC cités dans ce sondage est justement d'avoir un code propre, structuré et facilement maintenable, et c'est déjà assez pénible avec le mélange des balises JSP, scriplets Java et HTML dans les pages. Ajoutes JS à l'équation et ça devient encore plus pénible

[sinok]

C'est vrai qu'avec ExtJS le rendu est époustouflant, mais franchement, au vu du code que ça nécessite, ça n'en vaut pas la peine : l'un des buts fondateurs de la majorité des frameworks MVC cités dans ce sondage est justement d'avoir un code propre, structuré et facilement maintenable, et c'est déjà assez pénible avec le mélange des balises JSP, scriplets Java et HTML dans les pages. Ajoutes JS à l'équation et ça devient encore plus pénible

Pour moi ExtJS n'en envisageable que si on l'utilise pour l'intégralité de l'interface. Et ensuite les échanges se faisant via JSON ou XML. Dès que tu commences à mélanger ça devient vite un foutoir sans nom. Mais essentiellement, il n'est pas franchement nécessaire de faire un Mix de tout ça.

[djo.mos]

Pour moi ExtJS n'en envisageable que si on l'utilise pour l'intégralité de l'interface. Et ensuite les échanges se faisant via JSON ou XML. Dès que tu commences à mélanger ça devient vite un foutoir sans nom.

On est bien d'accord la dessus

[nicorama]

On est bien d'accord la dessus

Pour l'instant, je ne trouve pas. Je structure mon applis web en quelques pages JSP qui sont des entrées aux Applications Ajax. La page JSP est faite à partir d'un Template HTML géré par Dreamweaver.

Chaque page JSP, avec JSTL, beans et tags, configure en quelque sorte l'appli Ajax : ce user est un Teacher ayant une Classe principale, donc je showModuleClassePrincipale(). Le reste étant bien sûr dans des fichiers Javascript.

Doit surement y avoir mieux, mais JSF est tellement lent ! Quant à Wicket, il faut faire un gros travail de CSS pour avoir un rendu sympa. Avec Ext-Js, j'en ai pour 2-3 ans avant d'être rattrapé niveau rendu, et c'est quand super simple de faire des petits Panel-Module indépendants.

Ca s'intègre d'ailleurs parfaitement à Prototype ce qui simplifie beaucoup de choses. Après quelques années de recherches (j'ai acheté mon bouquin JSF il y a deux ans), je suis enfin satisfait d'une solution sur le poste client

[sinok]

Ce que je disait c'est que tu quand tu fais de L'extjs il vaut mieux éviter de le mélanger à JSP ou tout autre techno, en effet Ext propose en interne tout ce qui est nécessaire pour faire ton interface.
Dans ce cas il suffit de limiter ta partie java à la partie serveur et ExtJS s'occupera de l'intégralité de la partie client.
Essentiellement je ne vois absolument pas le besoin de mélanger Ext et jsp et tags JSTL, syntaxiquement si tu continue dans ce chemin là tu vas te retrouver avec quelquechose de realitivement lourd et pas des plus maintenables.
La seule chose à faire est de communiquer tes infos via JSON/XML depuis le serveur.
En fait la configuration elle même de la page est aisément faisable via Ext, pourquoi venir y mélanger ces horribles tag JSTL?

[nicorama]

Pour éviter d'avoir trop d'objets métier dans ExtJs. Les JSTL (que j'adore) appelle les beans qui gèrent du code complexe. J'ai aucune envie de réécrire ca en javascript, ou de multiplier les appels ajax au serveur.

Pour raison de maintenance, et pour garder le code propre

[KooR.fr]

Je vais certainnement pas être très objectif (pour cause de participation au développement du projet considéré) mais le framework Ellipse a de quoi se défendre, comparé aux autres technologies.

Pour vous en convaincre, je vous propose le tutorial accessible à partir de l'adresse suivante (cliquez sur le logo Ellipse au centre) :

http://www.infini-software.com

Je suis preneur de tous les avis (constructifs).
Merci.

[toomsounet]

Sinon pour ce que ça vaut :
rouge = java server faces
jaunes = spring mvc
bleu = struts 2



http://www.google.com/trends?q=strut...ate=all&sort=0

Je n'ai pas le même résultat.

Après, les critères de recherche ne sont pas les mêmes. JSF semble bien s'imposer malgré ses défauts.

Vert:java struts1, bleu:java JSF, rouge:java struts2, jaune:java wicket

[benwit]

Mouais, pas très convaincu sur l'interêt de ces graphes
car en rajoutant gwt (vert) et wicket (bleu foncé) en plus de struts 2 (bleu clair), de jsf (rouge) et de spring mvc (orange) :

[mesken]

Liser un peu ce lien et donnez moi votre point de vue. http://www.tomsquest.com/blog/les-limites-de-wicket/
Quelqu'un a-t-il déjà utilisé http://www.extjs.com/examples/#overview que je trouve génial ?

En ce qui concerne Spring, je suis d'accord qu'il est à tout faire, mais je crois que ceci est intéressant pour des applications moyennes. Lorsqu'il s'agit des applications de grandes envergures, il serait mieux d'utiliser Spring coté frontend et developper ses propres EJB au niveau middleware selon l'architecture et la conception définie. C'est vrai il faut rendre la vie facile au développeur, mais trop de vie facile.....

[joseph_p]

Liser un peu ce lien et donnez moi votre point de vue. http://www.tomsquest.com/blog/les-limites-de-wicket/

Hum, bonne idée que de demander une réaction J'avais déjà répondu un peu sur la montée en charge, mais pas de façon plus étendue, ce que je me propose de faire.

Ceci dit, je trouve qu'un tel débat aurait sa place dans le forum wicket, du coup j'y créé le sujet Les limites de Wicket: commentaire de texte et j'y ai fait mon, hum, *petit*, commentaire de texte

Au plaisir d'y lire d'éventuelles réactions !
++

[mesken]

Salut,

Dans le but de la conception d'un projet robuste et de très grande envergure, intégrant plusieurs modules extensible et paramétrable, d'une durée d'environ 12 mois. Nous avons décider tout évidement d'adopter J2EE. Et je suis en formation pour 60 jours. Mais pendant cette formation je réfléchis au fur et à mesure sur le choix de la solution et l'architecture selon l'éventail des solutions qui me sont proposées que ce soit par le formateur ou dans les multiples bouquins que je parcours pour m'outiller autant que possible afin de commencer avec des bases solides sur lesquelles sera bâti le reste de l'édifice. Et j'aimerai avoir des éclaircis sur les points suivants :

1) J'ai lu quelque part que Spring est très intéressant mais pour des applications de grande envergure, les EJBs serait l'idéal. Quelqu'un as-til un éclairci ?
2) De même pour Hibernate qui est intéressant, mais j'entends dire qu'il a aussi des inconvénients. S'il vous plait puis-je savoir lesquels ? Et quand choisir les EJBs ou Hibernate ?
3) La troisième préoccupation réside au niveau du Framework, dans la mesure où l'application aura les caractéristiques décrits par joseph_p plus haut et j'ai beaucoup aimé les détails donnés ici et les choix des un et des autres avec les avantages de Wicket, et puis je tombe sur l'article suivant qui parle des limites de wicket http://www.tomsquest.com/blog/les-limites-de-wicket/, j'hésite encore un peu. J'ai aussi entendu parlé de GWT. et de EXT JS http://www.extjs.com/examples/#overview qui m'a intéresse avec des Démo complexes et semblables à nos besoin.
Vos conseils sur ces trois points m'aideront à continuer à progresser dans mes décisions finales.

Merci

[benwit]

Quelqu'un a-t-il déjà utilisé http://www.extjs.com/examples/#overview que je trouve génial ?

Oui, j'ai déjà utilisé. C'est vrai que question look, c'est homogène.
Personnellement, même si c'est possible (avec une grande rigueur), coder avec javascript de gros projets, je trouve ça vite pénible.
Je leur préfère largement leur version gwt car le codage dans un langage comme Java est bien plus agréable (meilleurs outils, typage statique).
Après, c'est clair que GXT reste perfectible (par rapport à GWT moins riche graphiquement)

J'ai lu quelque part que Spring est très intéressant mais pour des applications de grande envergure, les EJBs serait l'idéal. Quelqu'un as-til un éclairci ?
2) De même pour Hibernate qui est intéressant, mais j'entends dire qu'il a aussi des inconvénients. S'il vous plait puis-je savoir lesquels ? Et quand choisir les EJBs ou Hibernate ?

Spring, pour ce que j'en connais, c'est diverses briques que tu utilises selon tes besoins. Il a l'IOC très pratique. Il y a Spring MVC, une autre solution concurrente de JSF/Wicket/GWT) ...
Par EJB, si tu parles des EJB dernière version, c'est JPA et pas forcément incompatible avec Hibernate qui peut servir d'implémentation JPA.
Après, ces ORM, c'est bien mais assez boite noir quand même et pas forcément très simple avec GWT.

[Mako 5013]

Bonjour,

Personnellement, même si c'est possible (avec une grande rigueur), coder avec javascript de gros projets, je trouve ça vite pénible.

Jusque là, on est d'accord.

Je leur préfère largement leur version gwt car le codage dans un langage comme Java est bien plus agréable (meilleurs outils, typage statique).
Après, c'est clair que GXT reste perfectible (par rapport à GWT moins riche graphiquement)

Là par contre, je ne suis pas tout à fait du même avis. D'une part, la façon de faire de GWT est radicalement différente de la façon de faire de Ext JS, si bien qu'intégrer GWT au sein d'une architecture existante est réellement une difficulté. C'est presque toute l'architecture de ton modèle MVC que tu dois revoir, et si tu es habitué à développer avec Struts ou JSF par exemple, cela représente une sacré courbe d'apprentissage...D'autre part, je ne comprends pas la dernière phrase, GXT moins riche graphiquement que GWT ?!? Je me permets de mettre le lien vers les deux showcases, pour que chacun puisse se faire son avis, mais pour moi, il n'y a pas photo...
GWT
GXT

Mako

[benwit]

Pour ce qui est de ma préférence de GXT par rapport à Ext-JS, c'est bien évidemment pour une application complètement nouvelle (en considérant également qu'il faut apprendre la nouvelle approche de GWT).
S'il s'agit d'une application existante en struts, jsf ou autre, il est bien évident que Ext-JS s'intégrera beaucoup mieux, je suis bien d'accord.


Pour ta deuxième remarque, relis moi bien ...
Je dis :

GWT moins riche graphiquement

c'est GWT qui est moins riche graphiquement que GXT et pas l'inverse
il y a les showcases pour le vérifier comme tu dis

Après, quand je disais : GXT reste perfectible, c'est pas rapport au code interne.

Je mettais donc en balance les défauts de GXT (leur code) par rapport a ses avantages (richesse fonctionnelle)

[Mako 5013]

Pour ta deuxième remarque, relis moi bien ...

Effectivement, j'avais mal interprété tes propos. Voici comment j'avais lu ta phrase :

Après, c'est clair que GXT reste perfectible (par rapport à GWT il (GXT) est moins riche graphiquement)

D'où mon étonnement...Pour ce qui est du code interne de GXT, bien que n'ayant pas pu m'en rendre compte par moi-même, j'ai effectivement vu plusieurs avis disant que ce n'était pas le nirvana...

Mako