GWT avec plusieurs pages d'hôte dans une ancienne application

Question

J'envisage d'utiliser GWT comme frontal pour une application Web existante.

Je ne peux pas justifier une réécriture complète à 100% GWT en une seule fois. Il est probable que je migrerais des parties du système vers GWT progressivement. Cependant, par souci de cohérence, je voudrais utiliser le TabPanel, MenuBar, etc GWT comme éléments d'interface globale dès le premier jour.

À titre d'expérience pour voir comment les parties «héritées» du système pourraient être incorporées, j'ai fait ce qui suit.

Le modèle de page principale de l'application charge maintenant un petit module GWT 'wrapper' sur chaque page. Ce module GWT recherche une sélection de DIV dans la page hôte générée dynamiquement. Si le DIV est trouvé, un widget approprié est mis en place, c'est-à-dire, menuBar, tabPanel.

Une grande partie de la configuration des widgets inclus peut également être insérée dans la structure hôte en tant que structures JSON. Par exemple, j'ai implémenté un adaptateur qui configure de manière dynamique un TabPanel de cette manière. J'ai également ajouté quelques widgets très simples qui chargent le HTML distant, etc.

En tant que prototype, tout cela semble fonctionner parfaitement et se charge rapidement. Cependant, il semble que les applications GWT sont vraiment conçues pour être exécutées à partir d'une seule page hôte, et non des centaines de celles générées dynamiquement. Quelqu'un peut-il mettre en évidence des problèmes que l'approche ci-dessus peut rencontrer, en particulier lorsque le module GWT augmente en taille? Je voudrais viser à garder le module wrapper legacy volontairement maigre. D'autres fonctionnalités seraient implémentées dans des modules distincts.

Comment d'autres personnes ont-elles intégré GWT dans leur frontal de façon progressive?

Answer 1

L'une des façons dont GWT a été conçu pour être utilisé est exactement comme vous l'avez utilisé. Nous l'avons fait dans plusieurs de nos applications - où il y a un module GWT avec plusieurs 'parties' qui sont chargées en fonction de si un identifiant donné existe sur une page ou pas. Donc je ne vois pas que vous aurez des problèmes du tout. Nous utilisons souvent cette approche même pour de nouvelles applications Web, où nous voulons juste quelques widgets sur la page, plutôt que de coder l'application entière dans GWT. Cela ne fera pas une énorme différence, mais une chose que je suggère ne consiste pas à mettre le code JavaScript GWT dans votre modèle principal, mais plutôt de le mettre sur les pages qui en ont besoin. Il est vrai que si vous n'exécutez pas de HTTP, il est mis en cache pour toujours, mais il semble incorrect d'amener les gens à charger dans le module si ce n'est pas vraiment nécessaire sur cette page. Cela dépend bien sûr de la façon dont les gens utilisent votre site, s'ils sont susceptibles de le télécharger de toute façon, cela ne fera aucune différence.

Answer 2

Vous le faites correctement. Évitez d'éviter la tentation d'essayer de «minimiser» l'empreinte de GWT en la divisant en plusieurs applications distinctes.

La clé de la performance GWT est d'avoir le moins de téléchargements possible et de s'assurer qu'ils sont mis en cache. Le chargement d'un paquet de 250k une fois est bien meilleur que deux paquets de 200k et parce que la compression est meilleure avec des fichiers plus volumineux, vous commencez vraiment à en récolter les bénéfices.

y-slow & firebug peut être très utile quand il s'agit de vous convaincre de cela.

Une astuce de performance que vous pourriez vérifier est disponible dans le chapitre exemple ici: http://www.infoq.com/articles/progwt Il montre un mini-architecture autour de widgets de chargement GWT dans un certain nombre de machines à sous et des données pré-peuplant des variables JavaScript. Cela permet à vos widgets GWT de se charger et de ne pas avoir besoin d'un second HTTP GET pour obtenir les données qu'ils utilisent. En pratique, j'ai trouvé que c'était une belle amélioration de la performance.