Découpage de l'interface graphique.

Bonjour,

En dev web classique (orienté serveur), on peut découper la gui en différentes pages (pour les différentes vues) qui sont envoyés sur le client au fur et à mesure de la navigation dans la gui.

En dev web gwt (orienté client), la gui est représenté par des classes Java compilées en Javascript. Bien entendu, on peut aussi découper notre code en différentes classes (ce qui est fait dans l'exemple KitchenSink de google)
En revanche, au final, un seul fichier js est généré (un par module).

Ce qui me dérange, c'est que pour une application qui possède beaucoup de vues (ie, beaucoup d'écrans) je crains que le code js généré deviennent énorme à télécharger la 1° fois (même s'il est optimisé) et lourd à gérer par le navigateur (s'il est chargé complètement).

Vous n'avez pas du rencontrer ce problème pour de "petites interfaces graphiques" : une vingtaine d'écrans. Mais si vous avez de multiples vues, comment avez vous fait ?

- Découpage en modules indépendants (un js par modules) et on passe de l'un à l'autre classiquement (par url).
- Module principale + iframe pour modules secondaires
Inconvénient : plus possible d'interagir entre modules secondaires/principal.

J'ai vu qu'on peut faire plusieurs point d'entrée par modules mais qu'ils sont malheureusement tous chargés au chargement du module. Je ne vois pas trop l'interet ? Pourquoi gwt ne génèrait pas plutôt un fichier js par entry point qu'il téléchargerait au fur et à mesure ?
Qu'en pensez vous ?

J'attends vos commentaires. Merci.

Oui c'est un problème fréquement rencontré dans l'édification d'applications webs 2.0 lourdes. Ce problème est l'un de ceux qui nous a fait renoncer à GWT pour l'utilisation plus classique d'une lib javascript (extjs).

La meilleure solution est le découpage de l'appli en grands domaines fonctionnels indépendants obéissant à l'enchaînement classique par url. Mais il existe d'autres techniques plus dans l'esprit 2.0 et qui étonnament n'ont pas été mis en oeuvre dans GWT. Il est ainsi tout à fait possible d'injecter dynamiquement du javascript au fur et à mesure des besoins, au même titre que d'autres resources.

Merci Tommy pour ton commentaire.
Ce que tu dis est très juste.

Je me suis fait la même remarque sur l'injection de js au fil de l'eau.
Pour l'instant, je n'ai également rien vu de prévu dans gwt pour le faire mais peut être est-ce une méconnaissance de ma part.

Si un lecteur pense qu'il existe un moyen, je serai curieux de le connaitre.
Et dès fois qu'un concepteur de gwt passerait par ici, ça serait bien qu'il réfléchisse à ce problème.

Bonnes fêtes.

Bonjour,
dans le cas de notre application, nous avons utilisé la notion de package de fonctionnalité associé a un utilisateur et de deferred binding pour limiter le code javascript, mais en effet dans le cas d'un utilisateur ayant tout les option il charge tout le javascript.