Sinon pour ce que ça vaut :
rouge = java server faces
jaunes = spring mvc
bleu = struts 2
http://www.google.com/trends/viz?q=s...mg&ctab=0&sa=N
http://www.google.com/trends?q=strut...ate=all&sort=0
Version imprimable
Sinon pour ce que ça vaut :
rouge = java server faces
jaunes = spring mvc
bleu = struts 2
http://www.google.com/trends/viz?q=s...mg&ctab=0&sa=N
http://www.google.com/trends?q=strut...ate=all&sort=0
Perso, j'aime bien Azuki (www.azuki-framework.org), en même temps c'est moi qui l'ai fait ! :yaisse2:
Salut
Juste pour dire que ce serai bien que vous alliez découvrir Tapestry. C'est vraiment un très très bon framework. Il est très productif. Son gros défaut à mon avis c'est qu'il manque de docs bien faite pour faciliter sa prise en main.
Mais avec un p'tit effort, il vaut vraimement le coup.
Ca serait bien qu'il y ai plus de français qui s'y collent ;-)
Cyrille.
Je confirme, il faut essayer Tapestry 5. Venant du monde J2SE/Oracle, j'ai récemment (début avril 2008) changé de job et je suis aujourd'hui architecte (et pour le moment unique développeur mais ça va vite changer) et je m'occupe de la création d'un site de commande en ligne.
Le client est un grand laboratoire pharmaceutique (connu de tous) et le site est à destination des pharmaciens et des médecins.
Mes contraintes :
--> le design des écrans a été réalisé par une agence de communication (la plus connue), est plutôt léché et fait sans qu'un "techos" ne bride l'enthousiasme des designers.
--> le temps de dev: même pas 2 mois pour:
modéliser une bdd qui valorise des commandes avec des conditions commerciales complexes
comprendre et migrer les données de l'ancien site (sauce struts + ERP vraiment bof)
developper et tester le site
--> Les performances: l'ancien site étant ce qu'on appelle communément dans le jargon une "daube" (et pourtant Dieu sait que j'essaie toujours de respecter l'existant mais là... 1min10 pour avoir accès à l'écran de commande de... 70 articles !!!)
Aujourd'hui, le pari (appelons un chat un chat) va être tenu (le gros fonctionne) et je tiens absolument à remercier Tapestry en version 5.11 (et aussi maven 2 sans qui je n'en serai pas là 8-))
Pourquoi :
--> Il me fallait coller au plus près à ce que l'agence avait produit, et grace aux composants (Layout mon ami) et aux balises tml, j'ai pu rester dans qqchose que je connaissais bien, le html (ça a l'air comme les facelets de chez JSF)
--> Il fallait que j'optimise mon savoir J2SE à destination de la web app, et le fait de ne faire que du POJO m'a été d'un grand secours (en plus, si j'ai bien fait bcp de php y'a qques années, le coding dans la JSP ne me disait guère)
--> L'intégration de composants AJAX (script.aculo.us) pour :
la validation de formulaire (Ah... @Validate) + les regexp + les datefields
(quasiment uniquement ce dont j'avais besoin)
--> Grace à l'utilisation massive des @annotations et à l'absence d'XML de configuration, j'ai gagné un temps fou.
--> Les conventions de nommage sont tout le temps expliquées par HLS (le boss du projet) sur son blog, débattues et font souvent l'unanimité. Je les utilise sans avoir eu besoin de les determiner et cela me procure un gros gain de temps et apporte une vraie structuration à mon appli (vive l'archetype Maven).
--> Il va même être facilement possible de réutiliser le site en marque blanche car l'ajout de JS ou de CSS se fait aussi par @annotations dans le POJO
A cela on peut ajouter la facilité avec laquelle on peut implementer le patron de conception IOC (via l'annotation @Inject), la gestion des sessions (@ApplicationState), la persistence entre page (@Persist)...
Les désavantages:
--> Pas de doc... en français : mais j'ai habité 2 ans en Irlande alors ça va mais je comprends que cela puisse être rebutant
--> Si j'en lis vos descriptions, il me semble moins AJAX oriented que Wicket (que j'irais voir)
Les points en suspens:
--> Les performances me semblent très correctes mais il n'y a que 5 testeurs en parallèle. Wait & See (au pire on mettra des index de partout ;) )
--> on va avoir un nouveau developpeur: aura t'il des difficultés à se l'approprier ?
J'espère que vous comprenez pourquoi j'ai voté Tapestry... en version 5.
Notez que je l'avais choisi après une longue comparaison...
Si vous avez des questions et que j'ai le temps, je n'hésiterais pas à vous répondre...
PS: Salut Robert, on a taffé ensemble, je vais aller voir ton framework, ça me changera de ton middleware :)
Hello,
Je viens (moi aussi) de commencer à utiliser Tapestry 5 dans mon travail.
Avant de choisir ce framework, nous avons évidement essayé de se renseigner sur un maximum de framework.
Et la c'est la jungle, bon disons que les plus populaires sont:
- JSF
- Struts 1 & 2
- JBOSS Seam (basé sur JSF)
- Wicket
- Tapestry
Les contraintes été les suivantes:
- performance
- facile à integrer dans un (gros) projet existant, qui utilisait un peu Strut 1
- séparation forte entre le HTML et le code (un intégrateur nous fournit les pages HTML)
Struts 1 avait été une expérience douloureuse, Struts 2 semble intéressant, mais la migration de Struts 1 à Struts 2 paraissait périlleuse, en plus Struts 2 part un peu dans tous les sens (plusieurs systèmes de templates, plusieurs librairies de tag etc....)
JSF a un impact trop important sur le code HTML, il aurait fallut remplacer une grande partie du HTML par des tags JSF.
Les multiples implémentations de la spécification, pas toujours compatibles entre elles ne rassurent pas...
Seam est un peu un cas à part, c'est beaucoup plus qu'un simple framework MVC.
Nous avons donc hésité entre Wicket et Tapestry.
Wicket a l'air vraiment sympa, mais l'aspect complètement statefull aurait peut être posé des problèmes de perf.
L'impact vraiment faible sur le HTML est clairement un gros plus, par contre je trouve le code JAVA assez bordelique; Il faut gerer la hiérachie des composant, alors que cette hierachie et déjà présente dans le HTML, c'est un peu redondant non ?
Cet aspect rend le code vraiment verbeux.
Nous avons donc finalement essayé de passer à Tapestry.
On se heurte rapidement à un gros problème, la documentation est.... disons.... succinte ;)
Par contre un fois qu'on commence à comprendre le principe, ça devient un bonheur.
Pour ce qui est du HTML, il est possible d'avoir la même chose que wicket, avec juste des t:id="toto" sur les élèments, ensuite une petite annotation dans le code java et c'est bon :)
Autre point fort, le framework est vraiment penser pour les perf (voir le cycle de vie de pages notamment).
Les composant son vraiment facile a créer (pas d'héritage comme dans wicket) et à utiliser.
Je n'ai pas encore tester l'AJAX.
Pour moi il reste un seul point noir, je n'ai pas trouver comment personnaliser le mapping des URL, qui sont par convention l'image de vos packages.
Exemple, la class toto.java se trouve dans fr.mondomaine.monprojet.pages.private, on atteint cette page en allant sur /private/toto
Voila c'était un peu long, j'espere que je vous ai donné envis d'essayer :king:
Dernière chose, "Tapestry 5, building web application" par Alexander Kolesnikov est pas mal pour commencer.
Avoir les sources du projet (tapestry-core surtout) permet de comprendre rapidement le fonctionnement.
Avec ces deux derniers post, vous me donnez envie d'y jeter un oeil 8-)
Bonjour,
j'ai été séduit par l'approche de Jboss Seam, mais malheureusement je n'a pas eu le temp de me pencher plus dessus ( work oblige ), et il est vrai que j'aimerais le mettre en place sur un projet plus "personnel", auriez-vous un retour d'XP dessus ( pro / cons )
merci
Je me permets de rajouter mon avis de débutant autodidacte J2EE.
Après avoir commencé à regarder Struts et Tapestry, je me suis vite rendu compte que cette philosophie ne me convenait pas pour le développement.
J'ai préféré opter pour une architecture plus libre à base d'Ajax via DWR (qui s'appelle de la SOA si j'ai bien compris). Pour faire simple, DWR permet de présenter des objets java en javascript de façon transparente, il suffit d'appeler les fonctions souhaitées et traiter le résultat via une fonction callback (de l'Ajax quoi, mais sans s'occuper des HttpRequest).
Un exemple rapide pour ceux qui ne connaissent pas :
Java :
@RemoteProxy me permettant d'injecter un bean Spring via la classe SpringCreator (je travaille avec le combo classique Spring/Hibernate en dessous) mais ce n'est qu'une des solutions possibles.Code:
2
3
4
5
6
7
8
9
10
L'objet HttpServletRequest permet d'avoir les informations de session et est automatiquement passé à chaque fonction.
On peut aussi se passer des annotations et utiliser le fichier dwr.xml (mais pourquoi faire compliqué ...)
Après configuration de DWR dans le fichier web.xml (très simple) et ajout d'un lien vers le fichier .js généré par DWR, on peut utiliser directement le bean dans javascript de cette façon :
Cette méthode demande de développer d'un côté le code métier java (où dans mon cas une couche qui fait le lien entre le code métier et DWR) et de l'autre un traitement javascript pour l'affichage des valeurs (des outils très pratiques sont fournis par DWR pour l'injection HTML). Une bonne organisation et de la rigueur sont donc nécessaires pour garder un code clair et propre (surtout côté javascript où c'est vite le souk). Le passage de paramètres de javascript->java peut aussi poser problème si on a besoin de passer des objets un peu compliquées (j'ai eu le soucis avec des list de list) mais ça se configure via le fichier dwr.xml.Code:
2maClass.maFonction(param1, maFonctionCallback);
La grande souplesse d'intégration est vraiment très agréable pour moi, surtout que j'ai besoin de réutiliser les mêmes objets dans plusieurs pages en modifiant juste le traitement callback sur les valeurs de retour. Mon application est sans aucun rechargement de page ce qui est plus agréable à mon sens pour l'utilisateur, qui oublie qu'il se trouve sur un navigateur (très important dans mon cahier des charges)
Après, je n'ai pas assez poussé mes investigations dans les autres framework pour vraiment pouvoir dire que mon choix est meilleur qu'un autre mais il me convient bien pour l'instant.
J'espère que ça pourra en éclairer certains sur une solution alternative :)
Edit : j'ai oublié de préciser qu'un couplage de DWR avec un framework orienté composant est complètement possible.
Je participe à cette discussion intéressante :
je ne vais pas vous faire de la pub pour le meilleur selon moi, mais vous mettre en garde contre le pire framework de tous:
WebObjects d'Apple.:?:(:cry:
Totalement deprecated, mac de m... obligatoire, pauvre x-code de m... en guise d'EDI, un binding objet de la base à la mort-moi-le-noeud, j'en passe et des meilleures.
Un véritable enfer sur terre.
Il est possible de le faire tourner sur eclipse, grace à des courageux qui l'ont adapté (mais pas chez nous, 300Klignes à migrer). Mais à l'utilisation c'est pas glorieux.
En fait, j'ai l'impression qu'Apple l'a mis en OpenSource par manque de personnel pour le maintenir, et cerise sur le gateau: incompatible leopard.
Je souhaite bonne chance aux bleus-bite qui essayeront d'ajouter une image à leur projet en moins de 5h. Ou à ceux qui espèrent faire du sql pour taper leur base.
En bref les gars, si on vous parle de WO, passer votre chemin, en courant (c'est contagieux et honteux il parait comme maladie).
:salut:
Je suis assez sceptique à l'utilisation de Spring MCV et/ou Tapestry sur un point : faut-il mixer dans un seul framework la partie graphique (MVC) et la couche métier-database (EJB, persistence).
Les standards de Sun que sont JSF et JPA ont pour avantage de bien séparer le tout et d'être bon et complet pour les tâches qu'ils executent (même si JSF n'a pas forcemment des performances terribles).
Pour répondre à la question du débat : je n'utilise pas de framework. JSP (persistence écrite à la main) et Javascript (avec quand même Prototype) me suffisent amplement. Je compte néanmoins me mettre à JPA.
y a-t-il un IDE qui permet d'intégrer facilement Tapestry ou Wicket de manière assez intuitive pour la partie IHM ?
Euh ... je crains que tu te trompes sur ce coup là: ni Spring MVC ni Tapestry ne touchent à la couche persistence ou métier: ils ne touchent qu'à la partie présentation et contrôle.Citation:
Envoyé par nicorama
Je ne sais pas pour Taperstry, mais pour wicket, comme la partie présentation est du pur HTML (enfin, presque), n'importe quel éditeur HTML ferait l'affaire, or tous les IDEs Java du marché (eclipse, NetBeans, IntelliJ, etc.) offrent un tel éditeur.Citation:
Envoyé par Mascotte
Sinon, y'a aussi WicketBench (plugin eclipse) qui permet de simplifier les opérations fréquentes de Wicket (générer page HTML + Page Java en une seule étape, regrouper l'éditeur Java/HTML, etc.) mais il n'est pas très à jour (parapport à eclipse et à Wicket).
Pour Netbeans, y'a WicketSupport qui offre des Wizards pour u nprojet Wicket, page Wicket et Panel Wicket.
même réponse pour Tapestry, c'est "presque" du pur html (du .tml pour tapestry markup language mais y'a une combine pour taffer en html) avec en plus les balises des composants Tapestry standards ou créés.Citation:
Envoyé par djo.mos
Par exemple, si tu as toujours le même block d'adresse dans une commande, tu créés le composant "adresse" en html, et tu l'appelles dans ta page avec la balise <t:adresse/> (t pour Tapestry).
Exact, pour l'instant il n'y a pas (à ma connaissance) de plugin pour tapestry 5.
Mais en affectant la coloration des html aux fichiers .tml t'a deja la coloration syntaxique, la validation du xml (les composant tapestry doivent etre du xml valide), et les tags qui se referment tout seul (testé sous eclipse et netbeans).
Il manque que la completion en fait :aie:.
@Nicorama: Tapestry ne gère absolument pas la partie métier.
Pour chaque page web, tu creer un fichier .tml (xml avec le namespace de tapestry sur l'élément racine) et une classe Java (pur POJO, pas d'héritage)
Ensuite la classe java va te permettre de gerer les elements dynamique de ta page, mais tapestry ne gere absolument pas le métier.
Tapestry IoC te permet de découpler facilement la présentation du business :)
En fait, c'est l'un des points retenus contre Taperstry: le fait qu'Howard, un excellent programmeur je dois avouer, mais qui réinvente la roue avec son HiveMind ... or dans d'autres frameworks on peut utiliser Spring (JSF, Wicket, Struts, etc.) ou Guice (Wicket, ...).Citation:
Envoyé par skaalf
Pas faux :roll:.
Je crois que tu peux quand même utiliser spring.
(http://tapestry.apache.org/tapestry5/tapestry-spring/)
Je ne suis pas d'accord, mais ça n'a rien à voir avec Tapestry, je tiens à le préciser pour ne pas me faire taxer de "chauvinisme ;)Citation:
Envoyé par djo.mos
à partir du moment où on peut utiliser ou Spring ou Guice avec Tapestry, le fait de proposer un autre conteneur léger comme Hivemind (quoique c'est un peu différent le Tapestry Ioc), c'est donner "encore plus" le choix à l'utilisateur final. D'où l'existence des Pico, Azuki...
Sinon, on dit, tout le monde utilise Spring et on n'en parle plus. Je crois que cette concurrence est saine pour Spring lui même.
D'ailleurs, HLS explique qu'il reprend des idées de Guice mais il explique pourquoi il ne l'utilise pas.
Cette page explique la raison d'être de Tapestry IoC : http://tapestry.apache.org/tapestry5/tapestry-ioc/
Selon moi, cette concurrence est saine et positive
J'ai encore du mal à comprendre le but d'intégrer Spring à Wicket. Qu'est-ce que Wicket ne permet pas de faire (suffisamment bien) sans Spring ?
Rien justement ;)
Je veux dire que wicket et Spring ne jouent pas dans la même catégorie : Wicket s'occupe de la partie présentation/contrôle, tandis que Spring est utilisé pour plein d'autres choses dans les autres couches (métier, daos, etc.):
- Conteneur de beans/injection de dépendances
- Pour la gestion des transactions
- Pour appliquer des aspects
- etc.
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 :mrgreen:
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)
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/
Autre : ExtJS :mouarf:
Mais paramétré avec JSP; par exemple dans /home.jsp, en pseudocode
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
C'est un peu experimental, trouvé dans le train ce week-end. J'en saurais plus dans une semaine.
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 :aie:
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.Citation:
Envoyé par djo.mos
On est bien d'accord la dessus :ccool:Citation:
Envoyé par sinok
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.Citation:
Envoyé par djo.mos
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 :)
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?
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 ;)
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.
Je n'ai pas le même résultat.Citation:
Envoyé par Jester
http://www.google.fr/trends/viz?q=ja...mg&sort=0&sa=N
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
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) :
http://www.google.com/trends/viz?q=s...mg&sort=0&sa=N
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.....
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.Citation:
Envoyé par mesken
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 !
++
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
Oui, j'ai déjà utilisé. C'est vrai que question look, c'est homogène.Citation:
Envoyé par mesken
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)
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) ...Citation:
Envoyé par mesken
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.
Bonjour,
Jusque là, on est d'accord.Citation:
Personnellement, même si c'est possible (avec une grande rigueur), coder avec javascript de gros projets, je trouve ça vite pénible.
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...Citation:
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)
GWT
GXT
Mako
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 :c'est GWT qui est moins riche graphiquement que GXT et pas l'inverseCitation:
GWT moins riche graphiquement
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)
Effectivement, j'avais mal interprété tes propos. Voici comment j'avais lu ta phrase :Citation:
Pour ta deuxième remarque, relis moi bien ...
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...Citation:
Après, c'est clair que GXT reste perfectible (par rapport à GWT il (GXT) est moins riche graphiquement)
Mako