Les plus grands pièges du GWT? [fermé]

189

Je suis au début / au milieu d'un projet que nous avons choisi de mettre en œuvre avec GWT. Quelqu'un a-t-il rencontré des écueils majeurs dans l'utilisation de GWT (et GWT-EXT) qui n'ont pas pu être surmontés? Qu'en est-il du point de vue de la performance?

Quelques choses que nous avons déjà vues / entendues incluent:

  • Google ne peut pas indexer le contenu
  • CSS et le style en général semblent être un peu floconneux

Vous recherchez également des commentaires supplémentaires sur ces éléments. Merci!

Agartzke
la source
4
Dernièrement, j'ai remarqué que certains sites Web basés sur GWT apparaissaient correctement dans mes résultats de recherche Google, même si le code HTML sous-jacent n'inclut pas les informations que je recherche (examples.roughian.com a plusieurs de ces types de résultats). Il semble que l'indexeur Google doit effectuer un rendu JavaScript intelligent afin de déterminer ce qui apparaîtrait réellement sur une page une fois que tout est chargé.
StriplingWarrior

Réponses:

231

Je vais commencer 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 rapports de compilations de 20 minutes, mais les miennes durent en moyenne 1 minute environ.

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 considérablement accélérer les temps de compilation en ne construisant que pour un navigateur. Vous pouvez le faire en mettant ceci 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 correspond pas aux changements `` en direct '' que vous obtenez lorsque vous modifiez des éléments tels que des pages JSP ou Rails et que vous appuyez sur Actualiser dans votre navigateur.

Solution: vous pouvez donner plus de mémoire au mode hébergé (j'en ai généralement pour 512M) mais c'est toujours lent, j'ai trouvé qu'une fois que vous êtes assez bon avec GWT, vous arrêtez de l'utiliser. Vous apportez une grande partie des modifications, puis compilez pour un seul navigateur (généralement 20s de compilation), puis appuyez simplement 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, 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 mise en page 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'une conception HTML en une conception GWT sera toujours plus lente que de faire quelque chose comme la conversion d'une conception HTML en 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 des personnes qui connaissent GWT ou veulent l'apprendre.


Problème: GWT est un marteau comparé à quelque chose comme jquery ou tout simplement javascript. Il faut beaucoup plus de configuration pour le faire que d'inclure simplement un fichier JS.

Solution: utilisez des bibliothèques telles que 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 dans les deux sens via le mécanisme RPC.


Problème: Parfois, pour remplir votre page GWT, vous devez passer un appel au serveur lors du premier chargement de la page. Il peut être ennuyeux pour l'utilisateur de s'asseoir là 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 effectuer tous vos appels GWT ensuite, et les précharger sur la page, pour un chargement instantané. Voir ici pour plus de détails:

Accélérez le chargement des pages en pré-sérialisant vos appels GWT


Je n'ai jamais eu de problèmes avec le style CSS de mes widgets, prêts à l'emploi, personnalisés ou autres, donc je ne sais pas ce que vous entendez par là un piège?

En ce qui concerne les performances, j'ai toujours trouvé qu'une fois compilé le code GWT est 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 les paquets RPC natifs que vous obtenez si vous utilisez un back-end JAVA est assez compact.

rouille
la source
1
Nous avons rencontré plusieurs problèmes où divers styles / commandes de positionnement ne semblaient pas "prendre" - les styles n'étant pas utilisés là où ils auraient dû être, ou le dimensionnement d'un élément semblant ignorer la demande de le rendre à 100%. Identique à de nombreux défis CSS classiques - très probablement beaucoup d'erreurs utilisateur!
agartzke
@agartzke ouais, c'est CSS pour vous, et cela n'a surtout rien à voir avec GWT. C'est pourquoi nous employons des designers hautement qualifiés pour faire ce genre de choses pour nous. Bien faire les choses dans 4 navigateurs différents n'est jamais une tâche facile.
rustyshelf
1
Il y a beaucoup de nouvelles fonctionnalités intéressantes à venir plus tard cette année qui améliorent considérablement beaucoup de ces problèmes. Mode hébergé hors processus (OOPHM), CssResource (obduscation / minification de feuille de style), UiBinder (alias `` interface utilisateur déclarative '').
Mark Renouf
Je suis vraiment impatient de 2.0 mais je ne suis pas d'accord avec le fait que GWT soit le marteau. Si tel est le cas, jQuery et JavaScript sont au mieux un cludge. Mon point étant que je n'obtiens aucune réutilisation, je finis par copier-coller beaucoup de choses (par exemple: une zone de texte sur 4 pages qui se comporte de manière identique à chaque endroit). Cela ne veut pas dire que vous devriez jeter toutes vos anciennes applications. Je n'utiliserais (presque) jamais GWT pour ajouter des capacités à une application html / js existante. Les ressources CSS sont également dans l'incubateur et je les aime: stackoverflow.com/questions/1066250/gwt-html-file-with-css/… .
Chris Ruffalo le
2
Vous pouvez réutiliser JQuery autant que vous pouvez réutiliser GWT, je ne pense pas que ce soit un argument valide. Ils prennent tous les deux en charge l'héritage, puis peuvent tous deux être conditionnés pour être réutilisés (fichier .jar pour GWT, fichier .js pour JQuery). Je maintiens ce que j'ai dit que GWT est un marteau, vous devez le coder en Java, vous devez le compiler, vous avez beaucoup plus de choses à gérer. Si vous voulez briser un mur de briques, vous choisissez le marteau. Ce n'est pas une critique, c'est un argument valable. Le bon outil pour le bon travail.
rustyshelf
54

Nous travaillons avec gwt depuis près de 2 ans. Nous avons appris beaucoup de leçons. Voici ce que nous pensons:

  1. N'utilisez pas de bibliothèques de widgets tierces, en particulier gwt-ext. Cela 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.

  2. Utilisez gwt pour ne remplir que les parties dynamiques de vos applications. Donc, si vous avez des interactions utilisateur complexes avec de nombreux champs. Cependant, n'utilisez pas les panneaux qui l'accompagnent. Prenez vos pages fournies par le 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.

  3. Ne créez pas l'ensemble de l'application comme une page standard qui construit ensuite dynamiquement toutes les pièces. Si vous faites ce que je suggère au point 2, cela n'arrivera pas de toute façon. Si vous construisez tout de manière dynamique, vous allez tuer les performances et consommer d'énormes quantités de mémoire pour les applications de taille moyenne à grande. 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 d'or que j'utilise est de créer des pages comme vous faisiez une page Web standard. Puis découpez 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.

olibre
la source
J'ai ouvert une question concernant votre réponse sur stackoverflow.com/q/10025656/138585 . J'apprécierai si vous pouvez y jeter un œil.
Elad
20

Pièges que nous avons rencontrés:

  • Bien que vous puissiez gagner beaucoup de temps 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 (dans 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 connaisse CSS. D'après mon expérience, peu importe que la personne ne soit pas experte ... il suffit qu'elle ait de bonnes connaissances pratiques et qu'elle connaisse les bons termes pour rechercher sur Google si nécessaire.

  • Débogage entre les navigateurs. Gardez un œil sur le mode hébergé hors processus [ 1 ] [ 2 ] [ 3 ], avec un peu de chance dans GWT 1.6 ... Pour l'instant, il vous suffit de faire le bon travail avec le mode hébergé, puis d'utiliser le bouton "Compiler / Parcourir" , où vous pouvez jouer avec d'autres navigateurs. Pour moi, travailler sous Windows, cela signifie que je peux voir mon travail dans FireFox et utiliser FireBug pour aider à peaufiner et améliorer les choses.

  • IE6. C'est incroyable à quel point IE 6 rendra les choses différentes. J'ai adopté l'approche consistant à appliquer un style à la "fenêtre" la plus externe en fonction du navigateur afin de pouvoir avoir des règles CSS telles que:

    .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 d'intelligence GWT. Par exemple, si j'essaie d'utiliser une classe qui n'est pas gérée par l'émulation JRE, cela 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 squiggly rouge ... 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.)

jgindin
la source
18

GWT 2.0, qui devrait sortir dans les prochains mois, résout un grand nombre des problèmes discutés.

  • Créer des mises en page en utilisant une syntaxe semblable à 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 peut résoudre les problèmes de vitesse du mode hébergé discutés, entre autres avantages
  • "Optimisations du compilateur" - Compilation plus rapide, espérons-le

Vidéo de prévisualisation GWT 2.0 sur Google I / O

Adam Albrecht
la source
15

Pas "incapable d'être surmonté" mais un peu de douleur pour quelque chose de basique.

Traitement de la date:

GWT utilise la méthode obsolète, java.util.Datece qui peut entraîner un comportement inattendu lors du traitement des dates côté client. java.util.Calendarn'est pas pris en charge par GWT. Plus d'infos ici .

Exemples de problèmes associés:

Jla
la source
1
Deux ans plus tard, et c'est toujours le cas. Cela reste assez ennuyeux pour faire des calculs de date sur le client.
Joseph Lust
Le problème est la traduction (compilation) de java.util.CalendarJavaScript. Vous pouvez également consulter la classe de GWTCalendarUtil , Comment utiliser java.util.Calendar dans GWT et Comment effectuer des opérations de calendrier dans Java GWT? Comment ajouter des jours à une date? . Cheers;)
olibre
10

J'ajouterai quelques points à ceux déjà mentionnés:

  • Liaison / validation de données. GWT n'a pas de support de liaison de données / validation prêt à l'emploi, bien que certains projets dans ce domaine commencent à émerger. Vous vous surprendrez à écrire beaucoup de ceci:
TextField fname, faddress;
...
fname.setText (person.getName ());
faddress.setText (person.getAddress ());
...
  • Chargement paresseux. Puisque gwt est côté client, le chargement différé n'est vraiment pas une option. Vous devrez concevoir soigneusement vos RPC et vos objets de domaine afin de
    • envoyer toutes vos données d'objet nécessaires
    • évitez de récupérer toutes vos données avec impatience
    • Vous devrez également vous assurer que vous n'enverrez pas de proxies / objets non sérialisables. hibernate4gwt peut vous aider sur ces points.
  • Conception de l'interface utilisateur. Il est plus difficile de visualiser une interface utilisateur en 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 de belles URL ou un bookmarking complet. 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 toutes les boîtes à outils AJAX AFAIK.

À mon humble avis, il manque à GWT un cadre qui prend en charge immédiatement tous les problèmes mentionnés sur ce «fil».

Miguel Ping
la source
GWT est livré avec un système d'historique, par exemple History.newItem ("myItem", false); mettra #myItem dans l'url, pour faciliter la mise en favori. Pour gérer le chargement d'un signet avec votre application, utilisez simplement History.addValueChangeHandler (myHandlerMethod);
Ztranger
Ce n'est pas un système d'historique en soi, c'est juste un mécanisme pour écrire des jetons sur l'URL et gérer les notifications de changements de jetons. Vous devrez toujours écrire tout le code de l'application pour gérer les changements d'historique.
Miguel Ping
9

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 un GWT natif.

Quoi qu'il en soit, GXT est encore un peu immature et manque d'une communauté solide que je pense que GWT EXT a. Cependant, l'avenir est avec GXT, car il est GWT natif et développé par la société qui a créé 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 assez 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. Les tests unitaires avec JUnit sont également assez solides. Je n'ai pas encore vu de cadre de test unitaire 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/

JP Richardson
la source
1
Étant donné que cette question est toujours active et reçoit des votes, j'ai pensé fournir une mise à jour. J'ai complètement abandonné GXT (2009-2010) parce que je n'aimais pas les pratiques commerciales de Sencha Inc. J'ai ensuite abandonné GWT. J'ai redouté d'utiliser JavaScript tant que je le déteste. Autrement dit, jusqu'à ce que je l'ai vraiment compris. Maintenant, je développe presque exclusivement dans Node.js / AngularJS. Jetez dans Bootstrap 3 et vous pouvez créer un site Web impressionnant en beaucoup moins de temps que GWT. L'avenir est JavaScript, plus vous l'adopterez tôt, meilleur vous serez développeur.
JP Richardson
Quelle est votre opinion maintenant? (juste curieux) Merci.
Akos Lukacs
1
@AkosLukacs Je peux toujours signaler que j'utilise JavaScript et j'aime chaque élément! Comme je l'ai dit, je déteste JavaScript et c'est pourquoi j'ai choisi GWT. La réalité est que vous ne pourrez pas éviter JavaScript si vous envisagez de faire du développement Web, vous pouvez donc aussi bien l'adopter. Je me suis assez bien adapté à l'utilisation de JavaScript pour tout (j'ai fait un petit détour avec Go). En ce qui concerne ma pile, j'utilise Node.js / Express / React. J'étais un grand fan d'Angular et je le connais assez bien, mais je ne peux pas recommander Angular 1.x à quiconque commence avec JS car la courbe d'apprentissage est trop élevée.
JP Richardson
5

Pas de pièges majeurs que je n'ai pas 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 à moins que vous ne vouliez modifier l'apparence prête à l'emploi.

Ma recommandation est d'utiliser un widget "natif" de GWT sur une bibliothèque où ils sont proches des fonctionnalités.

Re indexation des moteurs de recherche: oui, le site n'aura normalement pas d'URL navigables (sauf si vous n'ajoutez que des widgets à des éléments d'un site Web régulier). Vous pouvez cependant faire une fonction d'historique en arrière / en avant.

Michael Neale
la source
4

J'ai utilisé GWT et GWT-ext ensemble sur un projet il y a quelque temps. J'ai trouvé l'expérience assez fluide en tant que développement Web, mais mon conseil serait le suivant:

Ne mélangez pas les widgets natifs GWT avec les widgets EXT. C'est déroutant 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 souhaiterais, c'est que je voulais un Panel qui soit a) dynamiquement actualisable b) cascadable

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. ;)

As
la source
4

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 vraie 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 le 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 de pouvoir oublier les problèmes entre navigateurs. 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 débogueur 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.

Steve Buikhuizen
la source
1
Je ne connaissais pas le filtre gzip - merci pour cette friandise.
agartzke
4

Légèrement hors sujet, mais le canal #gwt sur irc est très utile, au cas où vous auriez un problème persistant.


la source
sur quel réseau IRC le canal est-il utilisé?
tovare
C'est sur freenode (irc.freenode.net). Et c'est en fait ## gwt, mais vous y serez redirigé si vous tapez #gwt.
Stian
4

GWT est assez simple et intuitif.

Surtout avec la sortie d'UIBinder pour permettre aux widgets GWT d'être mis en page 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 l'écueil, est le 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 le 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. C'est 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 à la seconde).

GWT RPC demande un certain effort pour comprendre, mais avec 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 en tant que serveur GWT RPC. Cependant, puisque vous n'aviez pas demandé de réponses mais simplement des problèmes, je vais m'abstenir de faire de la publicité pour mon blog.

Alors. Je crois fermement 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.

Geek béni
la source
Je voudrais un lien vers vos articles de blog;)
ms-tg
h2g2java.blessedgeek.com
Blessed Geek
3

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 div spécifiques que nous voulions que GWT gère). Au moins à l'époque où nous l'avons utilisé, nous ne pouvions pas intégrer GWT à des parties de notre site Web qui n'étaient pas codées dans GWT. Nous l'avons fait fonctionner finalement, mais c'était un gros hack.

Ykaganovich
la source
3
  • 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


la source
3

GWT 2.4 a résolu bon nombre des problèmes mentionnés ci-dessus et une excellente bibliothèque de widgets vient de sortir de la version bêta (Ext GWT 3.0.4 alias GXT), qui est entièrement écrite en GWT, pas un wrapper d'une bibliothèque JS.

Douleur restante:

  • Manque de support du sélecteur CSS3, vous pouvez utiliser "literal ()" dans certains cas pour le contourner.
  • Manque de support pour CSS3 et les événements de navigateur modernes tels que transitionEnd .
  • Manque de prise en charge de la classe Java Calendar (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 la part de l'équipe Google GWT.
Joseph Lust
la source
2

En ce qui concerne GWT 2.4, utilisez Firefox lors du débogage de GWT, c'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 ce qui suit sous arguments -> arguments VM:

-Xmx512m -XX: MaxPermSize = 1024m -XX: PermSize = 1024m

Vous pouvez diviser votre serveur et votre client et utiliser ce qui suit sous arguments -> Arguments du programme: -codeServerPort 9997 -startupUrl http: // yourserver / project -noserver

De plus, pour éviter d'actualiser votre serveur à chaque modification, 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

Gal Bracha
la source
1

Un écueil majeur est que vous devez parfois attribuer explicitement un identifiant à ce qui devient finalement un élément HTML pour pouvoir utiliser certains styles CSS. Par exemple: un TabPanel GWT fera uniquement: survoler tabBarItems lorsque le tabBar du tabPanel a reçu un identifiant et que 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 :).

Confusion
la source
En général, l'attribution d'identifiants n'est pas une mauvaise chose si vous prévoyez de faire des tests avec Selenium.
Petteri Hietavirta
1

J'ai fait beaucoup de travail sur GWT récemment, et c'est ce que je dois dire:

  1. Le style CSS n'est parfois délicat, utilisez l'outil de développement IE dans IE et Firebug dans Firefox pour comprendre ce qui se passe exactement et vous aurez une idée claire de ce qui doit être changé.
  2. Vous pouvez utiliser des astuces pour demander à Google de l'indexer. Un site très célèbre est http://examples.roughian.com/ vérifier ses notes sur google. Un site beaucoup moins connu est www.salvin.in ( je n'ai pas pu résister à le mentionner), je l'ai optimisé en mots: page d'accueil de salvin (recherchez ces trois mots sur google)

Je ne connais pas grand chose à GWT-EXT, mais je suis moi aussi convaincu qu'il n'est pas nécessaire d'inclure des bibliothèques tierces.

Bonne chance pour votre décision :)

Salvin Francis
la source
1

GWT effectue le reniflement du navigateur au lieu de la détection des fonctionnalités et votre application ne fonctionnera pas sur certains navigateurs (en particulier les nouveaux)

Voici quelques références du problème:

Voici quelques références à la détection des fonctionnalités:

Extrait de Comparaison des frameworks JavaScript - Wikipedia

Eduardo
la source
1

L'équipe GWT a apporté de nombreuses améliorations importantes par rapport à la sortie de GWT 2.7 l'an dernier. Une faiblesse majeure de GWT était que la compilation prend trop de temps dans GWT 2.6 et versions antérieures. C'est maintenant parti GWT n'a pas de compilation incrémentielle qui est super rapide et ne compile que les modifications.

GWT 2.7 a maintenant ( Source ):

  • Des builds incrémentiels maintenant en quelques secondes
  • Des SourceMaps plus compactes et plus précises
  • Prise en charge GSS
  • JSInterop
  • Excellentes performances JavaScript
  • Taille de code plus petite
confiler
la source
1

L' enquête gwt est la meilleure façon d'obtenir des faits fiables . L'un des plus gros problèmes avec GWT a toujours été une longue période de compilation. Heureusement, cela s'améliore très rapidement, donc ce ne sera pas un problème important dans un proche avenir. 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 petit passe-partout. 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 l'ensemble de la communauté priorise systématiquement, les performances, la qualité du code, l'architecture, etc. par rapport à un codage facile.
N'oubliez pas que vous pouvez utiliser js dans GWT à tout moment, donc si vous avez des problèmes avec GWT, envisagez d'utiliser js. À la fin de la journée, GWT est js, vous pouvez donc faire tout ce que vous pouvez dans GWT dans js. En fait, la plupart des projets GWT utilisent js. Le problème est que GWT est radicalement plus compliqué. Néanmoins, cela vaut parfois la complexité supplémentaire.

Il convient de noter que GWT 3.0 apportera des améliorations massives.

jgleoj23
la source
0

Réutilisation des objets de service RPC.
Cela provoque des conditions de concurrence avec des symptômes qui ressemblent à une suspension de l'application.

antony.trupe
la source
Antony pourriez-vous nous en dire plus. Je fais un appel RPC au serveur et je m'attends à ce que l'interface graphique réponde jusqu'à ce que la demande revienne, mais elle semble se bloquer.
Brett Hannah
0

Pièges que j'ai rencontrés 1. Comportement différent en mode superdev. Par exemple, Someclass.class.getName () fonctionne parfaitement en mode Superdev et renvoie le nom complet de la classe. En mode productif, cela ne fonctionne pas.

  1. addWidget (widget) appellera le widget removefromparent ()
Marcel Pater
la source
0

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 était é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 toute la phase de conception Web: à la fois artistique et de programmation. Et c'est le plus proche du développement mobile, par exemple Android. En fait, GWT a été conçu pour générer différentes interfaces utilisateur natives, pas seulement du HTML. Bien que cela 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 gèle l'ensemble des fonctionnalités de base de GWT à un certain niveau (assez obsolète), puis s'appuie sur celui-ci. Gardez également à l'esprit que l'apparence et la sensation de bureau ciselées semblent ridicules de nos jours, sans parler des performances lentes, des tonnes de bogues et des fonctionnalités de compatibilité, en particulier sur les appareils mobiles. Vous voulez rester aussi proche que possible des contrôles natifs du navigateur, c'est-à-dire des listes déroulantes rendues sous forme d'éléments <select> natifs, et non de contrôles personnalisés.

Grâce aux tendances mobiles, l'UX dans son ensemble devient plus simple et plus plat, vous n'avez donc pas besoin de faire grand-chose pour styliser une application nette. Cependant, si vous voulez un look "3D", il existe également des dégradés. CSS3 a tout simplifié et GWT l'enveloppe d'une manière élégante orientée objet, contrairement au CSS brut. Alors ne vous découragez pas en regardant des commandes barebones plutôt laides dans la vitrine GWT. L'équipe GWT n'a intentionnellement offert aucun style, car c'est le travail du développeur.

Le reste est une programmation de navigateur à peu près conventionnelle en Java fortement typé avec de belles API concises. Mais bien sûr, ne jamais oublier que votre code s'exécute dans le navigateur, donc tous les appels sont asynchrones, par exemple, vous ne pouvez pas appeler les méthodes GWT-RPC dans une boucle (pour remplir une liste), mais vous devez les enchaîner de manière récursive si vous en venez à cela situation.

Il existe des "anti-modèles" auto-proclamés comme ne pas utiliser GWT-RPC. Cela m'a fait du bien jusqu'à présent: pendant 10 ans. La simplicité est la clé. Je ne penserais même pas une seconde à sacrifier des performances marginales pour l'élégance du code et la maintenabilité. de plus, ce n'est pas là que seraient 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 parvenez pas à trouver ou à styliser le gadget existant - lisez l'ensemble d'éléments HTML5 riches, vous pouvez toujours en envelopper 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 ne reçoit 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 expérience artistique (Photoshop / WordPress) ou réseau (Perl / Python).

Alex Rogachevsky
la source