Discussion :

[topolino]

Bonjour,

j'utilise un gridview avec pagination pour afficher des donnees, tout se passe bien. Par contre une demande fonctionelle vient se rajouter. Les utilisateurs veulent avoir le controle sur le PageSize, mon soucis est lorsque le pagesize est elevé alors l'affichage est tres tres lent du au poids du HTML genere.

Comment puis je palier à cela.

Merci

[tortuegenie]

Utilise le mode trace pour voir d'ou vient reellement ton probleme.

[Nathanael Marchand]

Bonjour,

j'utilise un gridview avec pagination pour afficher des donnees, tout se passe bien. Par contre une demande fonctionelle vient se rajouter. Les utilisateurs veulent avoir le controle sur le PageSize, mon soucis est lorsque le pagesize est elevé alors l'affichage est tres tres lent du au poids du HTML genere.

Comment puis je palier à cela.

Merci

Malheureusement, pas de solutions miracle à ceci! Il faut tout simplement limiter le pagesize à un range acceptable pour l'utilisateur au niveau du contenu et des performances. Pour demander plus, il faut passer par une autre méthode comme génerer un rapport sur un server etc.

[topolino]

Generer un rapport c'est a dire ?
Le pb est le poids de l'HTML genere (2Mo).

Peut on faire un buffer/flush pour que les lignes s'affiches au fur et a mesure ?

[ostenhard]

Bonjour,

J'ai dernièrement rencontré ce genre de problématique. Déjà as-tu testé ta page sur différents navigateurs ? Quel(s) est(sont) le(s) navigateur(s) cible(s) ?

Que contient ta page ? du javascript ? ... ?

Pour ma part, la dernière fois que j'ai eu ça, en désactivant tout le javascript, la page se chargeait quasi instantanément en affichant environ 300 lignes sur une dizaine de colonne.

Sinon comme il a été dit, que l'utilisateur puisse choisir un pagesize parmi une liste parmi laquelle les valeurs ont un compris acceptable réactivité/taille, c'est plutôt bien. Il faut juste prévenir l'utilisateur qu'avoir plus de lignes affichées sera plus long que moins.

[ostenhard]

Sinon pour réduire le poids de la page, il y a une bidouille qui consiste à réduire au maximum le HTML généré selon la pratique suivante (tu l'as peut-être déjà fait).

Prenons un exemple grossier, pour chaque cellule tu as défini un style dont le nom de la classe est "styleCellule", donc 12 caractères soit 12 octets. Tu as 100 lignes et 10 colonnes donc 1000 cellules donc dans le HTML généré tu auras 1000 fois "styleCellule" donc 12000 octets. Si tu renommes ton style en "c1" tu gagnes 10 octets à chaque fois donc tu as au final 2000 octets.

Bon c'est un exemple à la c**, mais j'ai eu le cas de développeur utilisant des noms à rallonge pour les styles, les noms d'images, ... qui une fois répétés X fois dans le html donnaient une page de taille importante.

[Nicolas Esprit]

Je suis du même avis : il y a des choses qui ne sont pas à faire.

La GridView ASP.NET n'est pas prévue pour afficher des milliers d'éléments sur une page Web. En règle générale, une page Web avec un tableau de 1000 lignes est une mauvaise page => très mauvaise ergonomie, faible lisibilité, performances pauvres, etc...

Il faut soit imposer aux utilisateurs, du fait des contraintes techniques, une limite acceptable (200, 500, 1000 ?), selon les colonnes à afficher, le poids de la page, etc.
Soit trouver un autre système qu'une GridView. PitMaverick78 parle d'un report, on peut aussi penser à une extraction Excel. On peut aussi mettre en place du Scrolling Ajax vertical sur la GridView (tu n'a plus à utiliser de pages, mais ne peut visualiser toutes les lignes en même temps).

Bref, pas de solution miracle à ce problème (qui n'en est pas un en fait).

Faut pas se laisser faire par le Business, l'expert informatique c'est toi, pas les utilisateurs. Tu argumentes et explique le pourquoi on ne peut faire ça, tu proposes une solution de contournement, mais tu n'acceptes pas des demandes farfelues

[Nathanael Marchand]

Je suis du même avis : il y a des choses qui ne sont pas à faire.

La GridView ASP.NET n'est pas prévue pour afficher des milliers d'éléments sur une page Web. En règle générale, une page Web avec un tableau de 1000 lignes est une mauvaise page => très mauvaise ergonomie, faible lisibilité, performances pauvres, etc...

Je plussoie entièrement!

Il faut soit imposer aux utilisateurs, du fait des contraintes techniques, une limite acceptable (200, 500, 1000 ?), selon les colonnes à afficher, le poids de la page, etc.
Soit trouver un autre système qu'une GridView. PitMaverick78 parle d'un report, on peut aussi penser à une extraction Excel. On peut aussi mettre en place du Scrolling Ajax vertical sur la GridView (tu n'a plus à utiliser de pages, mais ne peut visualiser toutes les lignes en même temps).

J'ai exactement le même problème sur l'appli que je développe actuellement: On affiche que le mois courant. "Oui, mais vous comprenez, des fois, on a besoin d'avoir un historique sur an, toussa toussa".
La réponse qu'on a donné: à besoin spécifique, réponse spécifique. Vous demandez a votre hiérarchie qui dispose de rapports xls, complets, générés par nos serveurs et vous utilisez ca dans votre Excel.

En plus, en général, passer par une demande comme ca, ca freine les ardeurs de ceux qui veulent des stats en long et en large et ils ne demandent que quand ils en ont besoin.

Bref, pas de solution miracle à ce problème (qui n'en est pas un en fait).

Faut pas se laisser faire par le Business, l'expert informatique c'est toi, pas les utilisateurs. Tu argumentes et explique le pourquoi on ne peut faire ça, tu proposes une solution de contournement, mais tu n'acceptes pas des demandes farfelues

Pfiou, si seulement c'était si simple
Généralement, la technique efficace est de demander quel est la réelle utilité fonctionelle de ce besoin. Bien généralement, le client aura du mal à justifier ou dira qu'il a une utilisation non conforme de l'appli, auquel cas tu peux le remballer!