Discussion :

[johan_barbier]

Hello,

XMLRAD 2005, delphi, MSSQL, XP.

Alors voilà ma question du jour...il se trouve que sur un écran, j'ai une longue liste tirée de ma bdd. En cliquant sur une ligne de cette liste, doit apparaître une combo list (2 en fait, pour être precis) reproduisant ma 1ère liste.
Sachant que j'ai pour l'instant 900 entrées dans cette liste (en fait 1800, c'éjà 2* 900, mais ne rentrons pas dans les détails), que pour chaque entrée, je dois répêter 2 * 900 entrées dans 2 combo lists...je mets mon pc à genoux.

En l'état, les combo list sont précalculées, dans des divs cachés (indexés pour savoir à quelle ligne on y fait référence). Sur un onclick (sur un bouton), on fait apparaître la combo list choisie.

ce que je voudrais, c'est soit:
- sur le onclick, je calcule les entrées de ma liste
- je recopie le contenu de la liste (afin de ne pas parcourir à chaque fois le flux xml).

Merci :-)

Johan

[RDM]

avant toutes choses techniques, j'aimerais évaluer la pertinence d'afficher 900 entrées ou plus d'une "liste"
a quoi sert cette liste ? ne peut -on pas faire un ecran de recherche qui permette de filtrer sur moins d'enregistrements ?

[johan_barbier]

Non. :-)

Je sais bien que 900 enregistrements, ça fait beaucoup.
Il s'agit de présenter à l'utilisateur certaines de ses données. Il peut les modifier, les effacer, en ajouter, ou simplement les consulter.
Ces données sont un import provenant d'un autre logiciel x.

Bref...non, l'utilisateur doit voir ces données dans leur totalité. Et on ne peut pas les filtrer car elles n'ont de sens que dans leur totalité (je veux dire par là, il y a 4 champs...dont l'id. Les 3 champs "visuels" doivent être vus ensemble pour que le tout soit cohérent. Chaque champ pris séparément n'a pas de cohérence, du moins dans ce contexte (par contexte, j'entends l'écran en question). Et il y a donc 900 lignes (pas champs hein, lignes) à afficher).

[johan_barbier]

Heu, et pour préciser sur le pourquoi du "pas de filtre"... le contenu des champs est identique...heu...désolé, j'ai du mal à m'exprimer ce matin!

Ce que je veux dire c'est que les champs ne représentent pas des "types", par exemple, sur lesquels ont pourrait filtrer (je ne veux voir que tel ou tel type).

Le pire, c'est que 900, c'est peut-être uniquement pour le début...

A la limite, on peut paginer, mais il faut pouvoir accéder à ce que l'on veut, quand on le veut. Et puis je ne suis pas convaincu qu'une pagination de 10 en 10 par exemple suffise à alléger assez la page : ça fera de toutes façons 10 lignes, et pour chaque ligne, 900 * 2 lignes (900 lignes par combo list).

En précisant encore, les combo lists ne contiennent chacune qu'un champ, pas les 3.

[RDM]

bon ok pourquoi pas...
pour la combo lis: c'est quoi ? quels sont les élément HTML que tu utilises
tu peux donner un exemple de ta combo list en XSL/HTML ?

[johan_barbier]

Oui, c'est une combo list html classique, avec une boucle xsl :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<select...>
  <xsl:for-each select="...">
    <option...>...</option>
  </xsl:for-each>
</select>

La boucle boucle sur un flux xml sorti d'une requête.
Et que ce <select>, donc, fait parti d'un template plus long, appelé lui aussi dans une boucle (boucle sur ma liste 1ère des 900 enregistrements, en fait).
Bref, une boucle sur une boucle (enfin sur 2, puisque j'ai 2 de ces select, quasi identiques (seul le nom du select change, en gros, le flux lui est identique, les valeurs aussi).

Imagine la liste comme ça :

A1 B1 x1
A2 B2 x2
A3 B3 x3
An Bn xn
...
sachant que dans la colonne des A, il y aura aussi des B, et inversement (le x sera différent, et aucune paire A-B ou B-A ne sera identique (pas 2 fois A1-B1 par exemple)...et B et A ne sont là que pour l'exemple. Ils sont du même "type", j'aurais pu ne mettre que des A en fait.

quand tu cliques sur A1 (ou un autre A, ou B de la 1ére colonne), tu obtiens la combo list suivante :
A1
A2
A3
An
B1
B2
B3
Bn

Pareil quand tu cliques sur B1 (ou sur une entrée de la 2de colonne).

On peut sélectionner donc n'importe quel A ou B pour le rempplacer par n'importe quel autre A ou B.

Quant à x, lui, il est éditable à la main (champ texte), et c'est un entier.

J'espère que c'est plus clair.

Si on reprend en gros -et en simplifiant- le principe des fichiers xsl actuels :

Un document principal, avec création de la liste 1ère, qui boucle sur le flux xml créé par une requête, et appelant pour chaque ligne, le template des combo lists.
Un js dans cette page affiche ou masque le td des combo lists présent dans la page b.

Incluse à ce document, une page b, déclarant le template permettant de créer les 2 combo lists dans un td caché.
Il y a notamment un bouton, évidemment, pour chaque ligne, appelant le js cité ci-dessus.
J'ai bien dit incluse, c'est un <xsl:import href="..." />

Outre ça, on a une frame dans la page principale, pour un partial update. Ce partial update donc, c'est une page c appelée avec des paramètres selon le bouton sur lequel on appuie, pour chaque ligne (suppression, édition, ajout...).

Voilà.
Je ne sais pas si c'est très clair...mais ce n'est pas moi qui ai créé ces pages, alors pas facile d'expliquer quelquechose qu'on a appris à comprendre peu à peu en décryptant le code ;-) Mais bon, c'est à peu près ça.

[RDM]

je n epeux que te donner des pistes/conseils:
ce que tu peux esayer de fire c'est de remplir tes combo par DOM HTML avec du javascript dynamiquement lorsque tu cliques sur les boutons pour eviter un retour sur le serveur et un triatement du flux XML qui doit êter déjà important.
Attention quand tu tests si tu es sur la même machine, il y un traitement Serveur _et_ Client qui peut effectivement mettre a genous ta machine, alors que sur des postes différents tu auras moins le problème.

[johan_barbier]

Oui, sans compter que ma machine n'est pas un foudre de guerre... ;-)

Ok, je vais voir du côté de ton idée et explorer ça.
Si j'arrive à quelquechose de viable, j'en ferai part ici, ça peut servir, sait-on jamais.

merci en tous cas :-)