Les plus gros pièges du GWT?
Je suis au début/milieu d'un projet que nous avons choisi de mettre en œuvre en utilisant GWT. Quelqu'un a-t-il rencontré des pièges majeurs dans l'utilisation de GWT (et GWT-EXT) qui n'ont pas pu être surmontés? Et du point de vue des performances?
Quelques choses que nous avons vues/entendues incluent déjà:
- Google ne pouvant pas indexer le contenu
- CSS et le style en général semblent un peu floconneux
Vous recherchez également des commentaires supplémentaires sur ces articles. Merci!
Je commencerai par dire que je suis un grand fan de GWT, mais oui, il y a de nombreux pièges, mais la plupart, sinon tous, nous avons pu surmonter:
Problème: Temps de compilation longs, à mesure que votre projet grandit, le temps nécessaire pour le compiler augmente également. J'ai entendu parler de compilations de 20 minutes, mais les miennes durent en moyenne environ 1 minute.
Solution: Divisez votre code en modules séparés, et dites à ant de ne le construire que lorsqu'il est modifié. De plus, pendant le développement, vous pouvez accélérer considérablement les temps de compilation en ne créant que pour un seul navigateur. Vous pouvez le faire en le mettant dans votre fichier .gwt.xml:
<set-property name="user.agent" value="gecko1_8" />
Où gecko1_8 est Firefox 2+, ie6 est IE, etc.
Problème: Le mode hébergé est très lent (sur OS X au moins) et ne se rapproche pas des changements "en direct" que vous obtenez lorsque vous éditez des choses comme JSP ou Rails pages et cliquez sur Actualiser dans votre navigateur.
Solution: Vous pouvez donner plus de mémoire au mode hébergé (j'ai généralement obtenu pour 512M) mais c'est toujours lent, j'ai trouvé une fois que vous êtes assez bon avec GWT vous arrêtez d'utiliser cela. Vous apportez un grand nombre de modifications, puis compilez pour un seul navigateur (généralement 20 secondes de compilation), puis appuyez sur Actualiser dans votre navigateur.
Mise à jour: Avec GWT 2.0+, ce n'est plus un problème, car vous utilisez le nouveau "mode de développement". Cela signifie essentiellement que vous pouvez exécuter du code directement dans le navigateur de votre choix, donc pas de perte de vitesse, en plus vous pouvez le firebug/l'inspecter, etc.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Problème: Le code GWT est Java et a une mentalité différente de la présentation d'une page HTML, ce qui rend plus difficile la prise d'une conception HTML et sa transformation en GWT
Solution: Encore une fois, vous vous y habituez, mais malheureusement, la conversion d'un design HTML en design GWT sera toujours plus lente que de faire quelque chose comme convertir un HTML conception à une page JSP.
Problème: GWT prend un peu de temps et n'est pas encore courant. Cela signifie que la plupart des développeurs qui rejoignent votre équipe ou maintiennent votre code devront l'apprendre à partir de zéro
Solution: Il reste à voir si GWT va décoller, mais si vous êtes une entreprise qui contrôle qui vous embauchez, vous pouvez toujours choisir les gens qui connaissent GWT ou qui veulent l'apprendre.
Problème: GWT est un marteau par rapport à quelque chose comme jquery ou simplement du javascript. Il faut beaucoup plus de configuration pour y arriver que d'inclure simplement un fichier JS.
Solution: Utilisez des bibliothèques comme jquery pour des tâches plus petites et simples qui leur conviennent. Utilisez GWT lorsque vous souhaitez créer quelque chose de vraiment complexe dans AJAX, ou lorsque vous devez transmettre vos données d'avant en arrière via le mécanisme RPC.
Problème: Parfois, pour remplir votre page GWT, vous devez effectuer un appel serveur lors du premier chargement de la page. Il peut être ennuyeux pour l'utilisateur de rester assis et de regarder un symbole de chargement pendant que vous récupérez les données dont vous avez besoin.
Solution: Dans le cas d'une page JSP, votre page a déjà été rendue par le serveur avant de devenir HTML, vous pouvez donc faire tous vos appels GWT puis et préchargez-les sur la page, pour un chargement instantané. Voir ici pour plus de détails:
Accélérez le chargement de la page en pré-sérialisant vos appels GWT
Je n'ai jamais eu de problème de style CSS avec mes widgets, prêts à l'emploi, personnalisés ou autres, donc je ne sais pas ce que vous entendez par être un piège?
En ce qui concerne les performances, j'ai toujours constaté qu'une fois le code GWT compilé rapide et que les appels AJAX sont presque toujours plus petits que l'actualisation d'une page entière, mais ce n'est pas vraiment unique à GWT, bien que le les paquets RPC natifs que vous obtenez si vous utilisez un back-end Java sont assez compacts.
Nous travaillons avec gwt depuis près de 2 ans. Nous avons appris beaucoup de leçons. Voici ce que nous pensons:
N'utilisez pas de bibliothèques de widgets tiers, en particulier gwt-ext. Il tuera vos performances de débogage, de développement et d'exécution. Si vous avez des questions sur la façon dont cela se produit, contactez-moi directement.
Utilisez gwt pour ne remplir que les parties dynamiques de vos applications. Donc, si vous avez des interactions utilisateur complexes avec beaucoup de champs. Cependant, n'utilisez pas les panneaux qui l'accompagnent. Prenez les pages fournies par votre concepteur de stock existant. Découpez les zones qui contiendront les commandes de votre application. Attachez ces contrôles à la page dans onModuleLoad (). De cette façon, vous pouvez utiliser les pages standard de votre concepteur et également faire tout le style en dehors du gwt.
Ne créez pas l'application entière comme une page standard qui crée ensuite dynamiquement toutes les pièces. Si vous faites ce que je suggère au point 2, cela ne se produira pas de toute façon. Si vous construisez tout dynamiquement, vous réduirez les performances et consommerez d'énormes quantités de mémoire pour les applications moyennes à grandes. De plus, si vous faites ce que je suggère, le bouton de retour fonctionnera très bien, tout comme l'indexation des moteurs de recherche, etc.
Les autres commentateurs ont également fait de bonnes suggestions. La règle générale que j'utilise est de créer des pages comme si vous faisiez une page Web standard. Découpez ensuite les pièces qui doivent être dynamiques. Remplacez-les par des éléments qui ont des identifiants, puis utilisez RootPanel.get( id ).add( widget ) pour remplir ces zones.
Pièges que nous avons rencontrés:
Bien que vous puissiez obtenir beaucoup de kilométrage en utilisant quelque chose comme GWT EXT, chaque fois que vous utilisez ce type de placage fin au-dessus d'une bibliothèque JavaScript, vous perdez la possibilité de déboguer. Plus d'une fois, je me suis cogné la tête sur le bureau parce que je ne peux pas inspecter (à l'intérieur de mon débogueur IntelliJ) ce qui se passe dans la classe de table GWT EXT ... Tout ce que vous pouvez voir, c'est que c'est un JavaScriptObject. Cela rend assez difficile de comprendre ce qui ne va pas ...
Ne pas avoir quelqu'un dans votre équipe qui connaît CSS. D'après mon expérience, peu importait que la personne ne soit pas experte ... il suffit d'avoir de bonnes connaissances pratiques et de connaître les bons termes pour google si nécessaire.
Débogage sur plusieurs navigateurs. Gardez un œil sur le mode hébergé hors processus [ 1 ] [ 2 ] [], avec un peu de chance dans GWT 1.6 ... Pour l'instant , il vous suffit de faire avancer les choses avec le mode hébergé, puis d'utiliser le bouton "Compiler/Parcourir", où vous pouvez jouer avec d'autres navigateurs. Pour moi, travailler sur Windows, cela signifie que je peux voir mon travail dans FireFox et utiliser FireBug pour aider Tweak et améliorer les choses.
IE6. C'est incroyable de voir à quel point IE 6 rendra les choses. J'ai pris l'approche d'appliquer un style à la "fenêtre" la plus à l'extérieur selon le navigateur afin que je puisse avoir des règles CSS comme:
.my-style { /* stuff that works most everywhere */ } .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
Enfin, assurez-vous d'utiliser un éditeur qui vous aide. J'utilise IntelliJ - il a beaucoup de sensations GWT. Par exemple, si j'essaie d'utiliser une classe qui n'est pas gérée par l'émulation JRE, elle me le fait savoir; si je spécifie un style pour un widget, et que je n'ai pas encore défini ce style, le code obtient le petit rouge ondulé ... Ou, en regardant le CSS, il me dira quand j'ai spécifié des attributs conflictuels dans un règle unique. (Je ne l'ai pas encore essayé, mais je comprends que la version 8 offre un meilleur support GWT, comme garder les interfaces et implémentations RPC "locales" et "asynchrones" synchronisées.)
GWT 2.0, qui devrait sortir au cours des prochains mois, résout beaucoup de problèmes discutés.
- Créer des mises en page à l'aide d'une syntaxe similaire à html/xml
- Chargement de script dynamique - seul le JS essentiel sera téléchargé initialement. Le reste sera téléchargé au besoin
- Mode hébergé dans le navigateur - Cela pourrait résoudre les problèmes de vitesse du mode hébergé discutés, entre autres avantages
- "Optimisations du compilateur" - Compilation plus rapide, je l'espère
Pas "incapable d'être surmonté" mais un peu pénible pour quelque chose de basique.
Gestion des dates:
GWT utilise le Java.util.Date Déconseillé qui peut conduire à un comportement inattendu lors du traitement des dates côté client. Java.util.Calendar N'est pas pris en charge par GWT. Plus d'informations ici .
Exemples de problèmes associés:
J'ajouterai quelques points à ceux déjà mentionnés:
- Liaison de données/validation. GWT n'a pas de support de liaison/validation de données prêt à l'emploi, bien que certains projets dans ce domaine commencent à émerger. Vous vous retrouverez à écrire beaucoup de ceci:
TextField fname, faddress; ... Fname.setText (person.getName ()); Faddress.setText (person.getAddress ()); ...
- Chargement paresseux. Puisque gwt est du côté client, le chargement paresseux n'est vraiment pas une option. Vous devrez concevoir vos RPC et objets de domaine avec soin afin de
- envoyer toutes les données de vos objets nécessaires
- évitez d'aller chercher toutes vos données
- Vous devrez également vous assurer de ne pas envoyer de proxys/objets non sérialisables. hibernate4gwt peut vous aider avec ces points.
- Conception d'interface utilisateur. Il est plus difficile de visualiser une interface utilisateur dans Java (panneaux, boutons, etc.) qu'en html.
- Support historique. GWT n'est pas livré avec un sous-système Historique, ni avec aucun sous-système pour les URL Nice ou les signets d'état. Vous devrez lancer le vôtre (bien qu'il prenne en charge les jetons Historique, ce qui est un début). Cela se produit avec tous les AJAX toolkits AFAIK.
À mon humble avis, GWT manque un cadre qui a un support prêt à l'emploi pour tous les problèmes mentionnés sur ce "fil".
Je travaille actuellement sur un projet qui utilise EXT GWT (GXT) à ne pas confondre avec GWT EXT. Il y a une différence, EXT GWT est celui qui est réellement produit par la société qui a écrit ExtJS la bibliothèque javascript. GWT EXT est un wrapper GWT autour de la bibliothèque ExtJS. GXT est GWT natif.
Quoi qu'il en soit, GXT est encore quelque peu immature et manque d'une communauté solide que je pense que GWT EXT a. Cependant, l'avenir est avec GXT, car il s'agit de GWT natif et effectivement développé par la société qui a fabriqué ExtJS. GWT EXT est quelque peu paralysé car la licence a changé sur la bibliothèque ExtJS, ralentissant ainsi le développement de GWT EXT.
Dans l'ensemble, je pense que GWT/GXT est une bonne solution pour développer une application Web. En fait, j'aime beaucoup le mode hébergé pour le développement, cela rend les choses rapides et faciles. Vous bénéficiez également de la possibilité de déboguer votre code également. Les tests unitaires avec JUnit sont également assez solides. Je n'ai pas encore vu un excellent framework de tests unitaires JavaScript qui me semblait suffisamment mature pour tester une application d'entreprise.
Pour plus d'informations sur GWT EXT: http://gwt-ext.com/
Pour plus d'informations sur EXT GWT (GXT): http://extjs.com/products/gxt/
Aucun piège majeur que je n'ai pu surmonter facilement. Utilisez fortement le mode hébergé. Comme vous utilisez GWT-ext, vous n'aurez presque jamais besoin de toucher CSS vous-même, sauf si vous souhaitez modifier l'apparence prête à l'emploi.
Ma recommandation est d'utiliser un widget GWT "natif" sur un widget de bibliothèque où ils sont proches dans les fonctionnalités.
Réindexation des moteurs de recherche: oui, le site n'aura pas d'URL navigables normalement (sauf si vous ajoutez uniquement des widgets aux éléments d'un site Web normal). Vous pouvez cependant faire une fonctionnalité de retour/avant de l'historique.
GWT est assez simple et intuitif.
Surtout avec la sortie d'UIBinder pour permettre aux widgets GWT d'être disposés en XML puis codés en Java.
Donc, si vous avez utilisé d'autres outils de conception Ajax ou Flash, ou Silverlight, etc., GWT est très facile à apprendre.
Le principal obstacle, sinon le piège, est GWT RPC. La raison même pour laquelle vous souhaitez utiliser GWT est à cause de GWT async RPC. Sinon, pourquoi ne pas simplement compter sur CSS pour formater votre page?
GWT RPC est cet élément qui permet à votre serveur d'actualiser les données sur votre serveur sans avoir à actualiser la page. Il s'agit d'une exigence absolue pour des pages telles que le suivi de la performance des stocks (ou la dette nationale et publique actuelle des États-Unis ou le nombre de bébés à naître avortés dans le monde entier par la seconde).
GWT RPC demande un certain effort pour comprendre, mais compte tenu de quelques heures, tout devrait être clair.
Au-dessus de cela, après avoir fait des efforts pour apprendre GWT RPC, vous découvrez enfin que vous ne pouvez pas utiliser les JSP comme composant de service pour RPC, à moins que ... J'ai une série en 8 parties (je pense) sur mon blog sur la façon d'utiliser JSP comme le service GWT RPC. Cependant, comme vous n'aviez pas demandé de réponses mais seulement des problèmes, je m'abstiendrai de faire la publicité de mon blog.
Alors. Je suis convaincu que les pires obstacles/pièges à l'utilisation de GWT sont de savoir comment déployer correctement GWT async RPC et comment lui permettre d'utiliser les serveurs JSP.
Légèrement hors sujet, mais la chaîne #gwt sur irc est très utile, au cas où vous auriez un problème persistant.
J'appuie le commentaire de ykagano, le plus gros inconvénient est de perdre le V dans MVC. Bien que vous puissiez séparer la véritable classe d'interface utilisateur du reste de votre code côté client, vous ne pouvez pas facilement utiliser une page HTML générée par un graphiste/concepteur Web. Cela signifie que vous avez besoin d'un développeur pour traduire HTML en Java.
Obtenez un éditeur d'interface utilisateur wysiwyg, cela vous fera gagner beaucoup de temps. J'utilise GWTDesigner.
Le plus gros avantage de GWT est d'oublier les problèmes de navigation croisée. Ce n'est pas 100% mais enlève presque toute cette douleur. Combiné avec l'avantage du débogage en mode hébergé (par opposition à Firebug qui est excellent mais pas le même qu'un Java), il donne au développeur un énorme avantage dans la génération d'applications ajax complexes.
Oh et c'est rapide à l'exécution, surtout si vous utilisez un filtre gzip.
J'ai utilisé GWT et GWT-ext ensemble sur un projet il y a quelque temps. J'ai trouvé l'expérience assez fluide lors du développement Web, mais mon conseil serait le suivant:
Ne mélangez pas les widgets natifs GWT avec les widgets EXT. C'est confus comme l'enfer, car généralement les noms sont les mêmes (GWT.Button ou GWText.Button?)
Une chose qui m'est arrivée qui a vraiment rendu le code plus complexe que je ne le souhaitais, c'est que je voulais un Panel qui a) pouvait être mis à jour dynamiquement b) en cascade
Les panneaux natifs GWT sont dynamiques, les panneaux Ext sont en cascade. Solution? Un GWT.VerticalPanel enveloppant un panneau GWTExt ... Chaos. :)
Mais bon, ça marche. ;)
GWT 2.4 a corrigé bon nombre des problèmes susmentionnés et une excellente bibliothèque de widgets vient de sortir de la version bêta (Ext GWT 3.0.4 a.k.a. GXT), qui est entièrement écrite en GWT, pas un wrapper d'une bibliothèque JS.
Douleur restante:
- Faute de prise en charge du sélecteur CSS3, vous pouvez utiliser "literal ()" dans certains cas pour contourner ce problème.
- Manque de prise en charge de CSS3 et des événements de navigateur modernes comme transitionEnd .
- Manque de Java Prise en charge des classes de calendrier (plusieurs années plus tard).
- Manque de support JUnit4 (5 ans et plus).
- Manque de feuille de route claire et de calendrier de sortie de l'équipe Google GWT.
- L'interface Async que vous devez écrire pour chaque interface de service ressemble à quelque chose qui aurait pu être généré automatiquement par le compilateur GWT.
- Les temps de compilation deviennent longs pour les grands projets
Mais pour un grand projet Javascript, c'est le meilleur choix
Nous avons eu beaucoup de mal à marier notre base de code GWT avec des modèles Web HTML que nous avons obtenus d'un concepteur Web (pages HTML statiques avec des identifiants de division spécifiques que nous voulions que GWT gère). Au moins à l'époque où nous l'avons utilisé, nous n'avons pas pu obtenir l'intégration de GWT avec des parties de notre site Web qui n'étaient pas codées en GWT. Nous l'avons finalement fait fonctionner, mais c'était un gros hack.
Concernant GWT 2.4, Utilisez Firefox lors du débogage de GWT, il est beaucoup plus rapide que d'utiliser Chrome. Et si vous n'utilisez que Firefox, pensez à mettre cette ligne dans votre fichier project.gwt.xml
<set-property name="user.agent" value="gecko1_8" />
De plus, si vous utilisez Eclipse, ajoutez les éléments suivants sous arguments -> VM arguments:
- Xmx512m -XX: MaxPermSize = 1024m -XX: PermSize = 1024m
Vous pouvez diviser votre serveur et votre client et utiliser les arguments suivants sous - Arguments du programme: - codeServerPort 9997 -startupUrl http: // yourserver/project -noserver
De plus, pour éviter d'actualiser votre serveur à chaque changement, utilisez JRebel http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ Et voici une démo en direct http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
GWT fait le navigateur Sniffing au lieu de la détection des fonctionnalités et votre application ne fonctionnera pas sur certains navigateurs (spécialement les nouveaux)
Voici quelques références du problème:
- google-web-toolkit Problème 2938: RFE: améliorer le fournisseur de propriétés user.agent pour faire face au "masquage" de la chaîne userAgent
- Iceweasel n'est plus pris en charge? - Aide Google Documents
- implémentations GWT pour chaque navigateur
Voici quelques références à la détection de fonctionnalités:
- Détection du navigateur (et que faire à la place)
- Détection de fonctionnalité: Script de navigateur de pointe
- Détection des fonctionnalités du navigateur
Extrait de Comparaison des frameworks JavaScript - Wikipedia
J'ai fait beaucoup de travail sur GWT récemment, et c'est ce que je dois dire:
- Le style CSS n'est parfois délicat, utilisez IE outil de développement dans IE et firebug dans Firefox pour comprendre ce qui se passe exactement et vous aurez une idée claire de ce que css doit être changé
- Vous pouvez utiliser des astuces pour que Google l'indexe. Un site très célèbre est http://examples.roughian.com/ vérifiez ses notes sur google. Un site bien moins célèbre est www.salvin.in (je n'ai pas pu résister à le mentionner), je l'ai optimisé en mots: page d'accueil de salvin (recherche google pour ces trois mots)
Je ne connais pas grand-chose à propos de GWT-EXT, mais je pense moi aussi qu'il n'est pas nécessaire d'inclure des bibliothèques tierces.
Bonne chance dans votre décision :)
La meilleure façon d'obtenir des faits fiables provient de enquête gwt . L'un des plus gros problèmes avec GWT a toujours été une longue période de compilation. Heureusement, il s'améliore très rapidement, ce ne sera donc pas un problème important dans un avenir proche. Un autre écueil est que GWT est considérablement plus compliqué car Java est un langage plus compliqué qui résiste aux mauvais codeurs à chaque étape du processus. De plus, la compilation ajoute une couche. Par exemple, js interop nécessite un Le problème fondamental est que GWT n'a pas été conçu pour être simple. Il a été conçu dès le départ pour des applications Web extrêmement complexes et toute la communauté priorise constamment, les performances, la qualité du code, l'architecture, etc. par rapport au codage facile.
N'oubliez pas que vous pouvez utiliser js dans GWT à tout moment, donc si vous rencontrez des difficultés avec GWT, envisagez d'utiliser js. À la fin de la journée, GWT est js, vous pouvez donc faire tout ce qui est possible dans GWT. En fait, la plupart des projets GWT utilisent js. Le problème est que GWT est considérablement plus compliqué. Néanmoins, cela vaut parfois la peine d'être compliqué.
Il convient de noter que GWT 3.0 apportera des améliorations massives.
L'équipe GWT a apporté de nombreuses améliorations majeures à la sortie de GWT 2.7 l'année dernière. Une des principales faiblesses de GWT était que la compilation prend beaucoup de temps dans GWT 2.6 et versions antérieures. Ceci est maintenant parti GWT n'a pas de compilation incrémentielle qui est super rapide et compile uniquement les modifications.
GWT 2.7 a maintenant ( Source ):
- Constructions incrémentielles désormais en quelques secondes
- Cartes source plus compactes et plus précises
- Prise en charge GSS
- JSInterop
- Excellentes performances JavaScript
- Taille de code plus petite
Un écueil majeur est que, parfois, vous devez attribuer explicitement un identifiant à ce qui devient finalement un élément HTML pour pouvoir utiliser certains styles CSS. Par exemple: un TabPanel GWT ne fera que: survoler tabBarItems lorsque la tabBar du tabPanel a reçu un identifiant et vous spécifiez un: hover sur cet elementId.
J'ai écrit sur d'autres inconvénients de GWT ailleurs, mais ils sont déjà couverts par la réponse de rustyshelfs :).
Réutilisation des objets de service RPC.
Cela provoque des conditions de compétition avec des symptômes qui ressemblent à la suspension de l'application.
Pièges que j'ai rencontrés 1. Comportement différent en mode superdev. Par exemple. Someclass.class.getName () fonctionne parfaitement bien en mode Superdev et renvoie le nom complet de la classe. En mode productif, cela ne fonctionne pas.
- addWidget (widget) appellera removefromparent () du widget
GWT est un chef-d'œuvre technologique. Il unit la programmation client et serveur, ce qui en fait une application cohérente - la façon dont le logiciel a été écrit avant la "superposition" et la façon dont il devrait être écrit. Il élimine les différents ensembles de compétences, les problèmes de communication entre les membres de l'équipe et généralement l'ensemble de la phase de conception Web: à la fois artistique et de programmation. Et c'est le plus proche du mobile, par exemple Android. En fait, GWT a été conçu pour générer différentes interfaces utilisateur natives, pas seulement HTML. Bien qu'il nécessite une énorme discipline pour assurer un tel découplage - pour garder vos couches internes indépendantes de la présentation.
La première erreur à éviter, qui m'a pris quatre ans à réaliser, consiste à utiliser des extensions tierces comme EXT-GWT alias GXT et SmartGWT. Il est très tentant de commencer à utiliser leurs jolis widgets de bureau au lieu d'investir dans votre propre style, mais je ne peux pas dire combien de problèmes j'ai eu avec SmartGWT jusqu'à ce que j'en ai finalement marre. En bref, il fige l'ensemble de fonctionnalités GWT de base à un certain niveau (assez obsolète), puis s'appuie dessus. Gardez également à l'esprit que l'apparence et la convivialité du bureau ciselé semblent idiotes de nos jours, sans parler des performances lentes, des tonnes de bugs et des fonctionnalités de compatibilité - en particulier sur les appareils mobiles. Vous souhaitez rester aussi proche des contrôles natifs du navigateur, que possible, c'est-à-dire des listes déroulantes rendues en tant qu'éléments <select> natifs, et non pas de certains contrôles personnalisés.
Grâce aux tendances mobiles, l'ensemble de l'expérience utilisateur devient plus simple et plus plat, vous n'avez donc pas besoin de faire grand-chose pour concevoir une application d'aspect net. Mais si vous voulez un look "3D", il y a aussi des dégradés. CSS3 a rendu tout facile et GWT l'enveloppe d'une manière orientée objet élégante contrairement au CSS brut. Ne vous découragez donc pas en regardant des commandes de barebones plutôt laides dans le GWT Showcase. L'équipe GWT n'a intentionnellement pas proposé de style, car c'est le travail du développeur.
Le reste est à peu près une programmation de navigateur conventionnelle en fortement Java avec de belles API concises. -Les méthodes RPC dans une boucle (pour remplir une liste), mais vous devez les enchaîner récursivement si jamais vous arriviez à cette situation.
Il existe des "anti-patterns" autoproclamés comme n'utilisez pas GWT-RPC. Ça a été bon pour moi jusqu'à présent: pendant 10 ans. La simplicité est la clé. Je ne penserais même pas une seconde à sacrifier certaines performances marginales pour l'élégance et la maintenabilité du code. en outre, ce n'est pas là que se trouveraient vos goulots d'étranglement - dans la base de données. Bien sûr, faites attention à la quantité de données que vous envoyez au client.
Et si vous ne pouvez pas trouver ou styliser le gadget existant - lire un ensemble d'éléments HTML5 riches, vous pouvez toujours en emballer un tiers. Je l'ai fait avec un jQuery FullCalendar populaire. Pas du tout sorcier. Tout le reste, comme Google Maps et Google Charts, a des wrappers GWT semi-officiels.
GWT est parfait. La seule raison pour laquelle il n'a pas assez d'amour est que les premiers utilisateurs d'Internet qui influencent encore l'industrie ne sont pas venus de l'informatique et des langages orientés objet pour les apprécier. Ils ont une formation artistique (Photoshop/WordPress) ou réseau (Perl/Python).