Version imprimable
Bonjour,
J'évalue en ce moment différents outils et frameworks web IHM.
- GWT
- Flex
- JQuery + elastic.
Très emballé au début par GWT je déchante pas mal à l'usage.
- Pas de datagrid digne de ce nom de base (en 2.1 un datagrid existe, mais pas de tri sur les colonnes).
- Pas d'aide aux contrôles de surface.
- Peu de widgets de base.
- Documentation moyenne et communauté pas si grande.
Je me trompe ? :roll:
merci de votre retour
Je ne suis pas d'accord.
La communauté est énorme, inscrit toi sur la mailing list.
Le point fort de GWT est la facilité d'étendre ou d'ajouter des fonctionnalité aux composants de base. GWT reste ainsi léger grâce à ce principe.
Pour le tri de colonne par exemple: En générale, dans les appli de gestion le tri doit se faire coté serveur afin que les requetes en base soit les moins couteuses possible en terme de ressource. C'est pour cette raison que le tri n'est pas proposé de base, c'est parce que dans la réalité on ne devrait pas les utiliser.
Les tri sur colonne coté client, c'est plutot dangereux en fait. Les developpeurs junior vont avoir tendance à les utiliser à tord et cela génère des problèmes de perfs.
Les controles de surface se font avec des annotations comme hibernate validator. Gwt2.1 fourni un mécanisme pour gérer cela il me semble. Perso j'ai factorisé ma gestion des erreurs dans un framework que tu peux trouver sur http://gwtop.tuxfamily.org/
La documentation est clair et précise. C'est avec elle que je m'y suis mis et elle m'a permis de maitriser parfaitement cet api.
Merci pour ta réponse :D
Je suis inscrit. C'est correct, mais je ne dirais pas énorme, il y a encore du chemin. Et en dehors de ce groupe, pas grand chose.Citation:
Envoyé par pvoncken
Oui, je te rejoins, mais je n'ai pas parlé de tri côté client. Je parle bien d'un fonctionnement avec accès au serveur à chaque action (pagination, tri, édition). Le composant de base ne propose aucun moyen de déclencher un tri, quelque soit l'endroit (ou je suis passé à côté).Citation:
Le point fort de GWT est la facilité d'étendre ou d'ajouter des fonctionnalité aux composants de base. GWT reste ainsi léger grâce à ce principe.
Pour le tri de colonne par exemple: En générale, dans les appli de gestion le tri doit se faire coté serveur afin que les requetes en base soit les moins couteuses possible en terme de ressource. C'est pour cette raison que le tri n'est pas proposé de base, c'est parce que dans la réalité on ne devrait pas les utiliser.
Les tri sur colonne coté client, c'est plutot dangereux en fait. Les developpeurs junior vont avoir tendance à les utiliser à tord et cela génère des problèmes de perfs..
Intéressant, merci pour le lienCitation:
Les controles de surface se font avec des annotations comme hibernate validator. Gwt2.1 fourni un mécanisme pour gérer cela il me semble. Perso j'ai factorisé ma gestion des erreurs dans un framework que tu peux trouver sur http://gwtop.tuxfamily.org/
La documentation est clair et précise. C'est avec elle que je m'y suis mis et elle m'a permis de maitriser parfaitement cet api.
++
Dans Gwtop tu trouveras ce qu'il faut pour réaliser le tri coté serveur.
Il faut que je rajoute des exemples, je vais essayer d'en fournir rapidement. N'hésite pas à faire un checkout comme indiqué sur le site, il y a un exemple dans le code dont tu peux t'inspirer.
Salut
J'utilise GWT Mosaic sur mon projet principalement pour ses qualités de mise en page (LayoutPanel)
Pour les datagrid j'ai eu la même déception, le CellTable de GWT ne gère effectivement pas les tris en natif.
Finalement j'utilise une PageScrollingTable de GWT Mosaic :
- chargement du contenu des tables page par page
- gestion du tri (côté serveur, évidemment)
Même si pour diverses raisons (bonnes ou mauvaises), tous le monde ne souhaite pas l'utiliser. Tu gagnes en richesse de widgets (pour des applications de gestion) avec GXT : http://www.sencha.com/products/gwt/ (à ajouter en complément)
Pour la maturité, ça date de 2006.
En 4 ans, ça a énormément progressé (grâce à google wave notamment)
Le problème de GWT, c'est de faire croire qu'il est facilement accessible. Il faut déjà connaitre un peu les techno de bases des applications web.
Nous travaillons également dans l'optique d'un choix:
GWT
ou
FLEX
Toutes les autres solutions ne "nous parlent pas".
.Net non car nous sommes dans un monde Java - à mon boulot - pour des questions de plateformes / portabilité
AJAX, non merci, trop de technos à se farcir à la main ou à utiliser des outils qui ne sont pas tous intégrés dans Eclipse; besoin absolu d'une API externe pour la partie widgets; FireDebug etc... le JavaScript, nous voulons l'éviter autant que possible
JEE, trop trop mais alors trop de frameworks, de possibilités, nous l'appelons le "fourre-tout". Beaucoup à mettre en oeuvre avant d'arriver à un résultat pro tant d'un point de vue métier que d'un point de vue présentation
Php, Python, Plone Zope => "berk", c'est subjectif je sais mais non - ça prendrait trop de temps de se former. D'un point de vue maintenance, c'est le "bord..." (vous terminerez ou pas :D)
un MIX de tout ça => trop de technos, outils qui partent dans tous les sens
HTML5 => pas abouti, pas fini, pas finalisé, manque gravement de réels outils pour gérer des données de manière tabulaire, tables, arborescence etc (widgets toujours et toujours)
Ceci n'est qu'un avis - personnel et partagé par mon équipe de dév. Il peut évidemment être critiqué; aucun soucis là dessus :)
----------------
Sinon, concernant GWT, nous ne l'abordons que parce qu'il y a des outils comme Ext-GWT ou GXT: franchement, facile à utiliser... Enormément d'exemples et de ressources:
à voir, pour ceux qui ne connaissent pas:
http://www.sencha.com/examples/explorer.html#overview
http://www.sencha.com/gxtdocs/
Vous pouvez également télécharger les examples, les ressources, et tout faire "tourner" localement.
Il est dispo en OpenSource ou en version Commerciale => Support
Google ayant racheté Instantiations => SWT, GWT, Swing Designer etc => (Eclipse Inside) Que du bonheur!?
Quand tu dis "le JavaScript, nous voulons l'éviter autant que possible"
Avec GWT, oui en développement.
Mais une fois compilé, c'est ce que tu auras.
Bien entendu, mais nous ne voulons pas développer directement en JavaScript, c'est un des points les pluss intéressants de GWT pour nous.Citation:
Envoyé par benwit
Alors ça, ça n'engage que toi...Citation:
Envoyé par M4v3rick
JEE est exceptionnel, et justement, très pro.
Pour la couche métier, les EJB3 sont du pur bonheur.
Pour la couche présentation, JSF couplé à RichFaces (et accessoirement Facelets) est au top.
Pour lier les 2, on peut également ajouter Seam.
D'un point de vue "rendu", c'est comparable à ExtJs and Cie, en plus facile.
Bref, on préfère presque toujours ce qu'on connait le mieux ;)
C'est exactement ce dont je parle:Citation:
Envoyé par OButterlin
Etant donné que nous ne sommes pas des "pros" JEE; il faut mettre en place un certain nombre de frameworks, configurer et écrire pas mal de code avant d'arriver à un résultat similaire à ce qu'on obtient aujourd'hui en GWT et en Flex (pour mon collègue).
Ce qu'on repporche à l'approche JEE, c'est qu'il y a une courbe d'apprentissage non négligeable. EJB, JPA, JSP servlet, JSF, JMS, RichFaces, etc...
Nous cherchons justemment des solutions les plus accessibles en terme de temps de développement pour nos futures applications web.
Il y a une courbe d'apprentissage, c'est indéniable, mais c'est vrai dans tous les cas.
Dans une application GWT (par exemple), tu auras également besoin d'un modèle métier, d'un accès aux base de données.
L'un dans l'autre, on a les même briques, sauf que JEE est un standard.
EE6 simplifie encore pas mal de choses, vraiment, je pense que ça vaut le coup d'investir un peu de temps.
Personnellement, les technos à base de javascript (comme ExtJs ou la version GWT) ne m'attirent pas, des bibliothèques "ajaxifiées" comme RichFaces ou PrimeFaces, là, oui.
Mais bon, tous les points de vue se défendent...