Discussion :

[jgfa9]

Bonjour,
Je développe une application web et je dois créer un formulaire pour lequel je me pose une question de base : ce formulaire complexe devrait théoriquement contenir environ 200 champs (!) répartis dans des onglets et des sous-onglets. Il me semble avoir auparavant rencontré un problème avec une jsp trop volumineuse... Est-ce que cela risque d'être le cas encore ici ?
Est-ce que ça dépend du serveur (dans mon cas, j'utilise Tomcat 5.5) ?
Merci de me conseiller avant que je ne me lance dans le développement de cet écran.
J.

[yolepro]

Bonjour jgfa9,

Si tu parles d'onglet, tu peux donc utiliser autant de formulaire que d'onglet pour que cela soit peut etre plus simple à gérer.

Dans tous les cas, les limitations dans les JSP peuvent être résolu par l'utilisation d'include.

[jgfa9]

Merci pour cette réponse rapide.
Qu'entends-tu par "include" ? jsp:include (je pensais que ça revenait au même, que c'était comme si on écrivait le code dans la même page), c:include, tiles:insert, ... ?
La page ne risque donc pas d'être trop lourde à charger (ou à compiler par le serveur) en utilisant une inclusion ?
Merci pour ces précisions.
J.

[OButterlin]

De mémoire, c'était plutôt le navigateur (IE) qui posait problème...
J'avais (à l'époque) contourné le problème en spécifiant la directive de compilation <%@ page buffer=2048kb ... %> (à toi de trouver la bonne taille)

a+

[jgfa9]

Merci également pour cette réponse.
Comment peut-t-on évaluer le buffer nécessaire ?

[OButterlin]

A priori, dans le navigateur (du moins avec Firefox), tu clique droit sur le document -> informations sur la page -> taille

[jgfa9]

Dans IE c'est bouton droit --> Propriétés (j'ai testé sur la page Yahoo sur laquelle je me trouvais, ça fonctionne) mais sur mon appli (localement ou sur le serveur) ça m'indique "Taille : non disponible"
Une autre idée ?
J'aimerais savoir si quelqu'un a déjà créé des formulaires très volumineux et s'il avait rencontré des problèmes (vitesse de chargement, d'enregistrement, etc) ...
Merci encore.

[OButterlin]

J'ai essayé avec IE (6) et j'ai la taille.

[jgfa9]

j'arrive à avoir la taille d'une page quelconque (sur Internet) mais sur mon appli (que j'y accède localement via localhost ou sur mon réseau via l'adresse IP) je ne l'ai pas, elle apparait comme "non disponible"...

[OButterlin]

Je ne sais pas, télécharge Firefox...
ou met une taille à la louche pourque ça passe...
Je ne suis pas persuadé que le problème reste d'actualité d'ailleurs...

[jgfa9]

Oui et à la base c'est ce que j'aimerais savoir : est-ce que je me prends la tête pour rien avec mes 200 champs ou pas ??
En tout cas, merci pour tes indications

[OButterlin]

200 champs, c'est pas encore énorme, à moins que ce soit 200 textarea avec un text monstrueux dans chacun

[crewstyle]

Je pense que le mieux serait de créer plusieurs formulaires (1 formulaire pour 1 onglet), et que pour chaque formulaire il faudrait y ajouter un input hidden spécifiant l'onglet.

De cette manière, arrivé sur la servlet traitant le formulaire, en récupérant le champs hidden tu sais exactement quels traitements faire et quelles variables récupérer.

Cordialement.

[OButterlin]

Cette méthode ne peut marcher que si tu envois un onglet à la fois.
Mais si tu as besoin de tous les onglets, ça coince...

[yolepro]

Rebonjour jgfa9,

Je vous rappelle que ce n'est pas un chat ici

Ne te prends pas trop la tête avec ca, 200 champs ca reste dans le raisonnable s'il ne sagit pas de textarea

Il arrive que dans certaine appli intranet de type gestion des congés on arrive à des tailles de source généré de lordre du méga.

La seule contrainte que tu aura sera de poster ton form en post et non en get.

[jgfa9]

Il s'agit de 200 champs "normaux" de type select ou text...
Pour la suggestion de créer un formulaire par onglet, j'y ai pensé mais ce qui m'ennuie un peu c'est que chaque formulaire devra donc être logiquement validé et soumis à chque fois qu'on change d'onglet et je ne trouve pas ça très intuitif pour l'utilisateur (qui devrait s'attendre à rester sur la même page)...
Mais merci pour cette suggestion... qui sera peut-être celle que je retiendrai au final...

[crewstyle]

... je ne trouve pas ça très intuitif pour l'utilisateur (qui devrait s'attendre à rester sur la même page)...

Je suis d'accord avec toi, mais en parlant de formulaire, donc de données que même une personne n'ayant pas de connexion à haut débit peut facilement afficher et rapidement, tu peux toujours jouer sur le javascript pour faire des affichages alternatifs sans recharger à chaque clique la page !

C'est le système par onglets par défaut. Le but c'est justement de ne pas avoir à recharger la page

(tu peux le gérer grâce aux DIV ayant un display à "none" qui passe à "inline" une fois l'onglet activé )

Mais bon, personnellement, je ne vois pas comment faire autrement si ce n'est qu'en d'en faire 1 seul formulaire à 200 champs (ce qui est relativement long pour un utilisateur, non ?)