Discussion :

[cyrano_de_bergerac]

Bonjour,

Je dispose d'un DataGrid. Chaque ligne est éditable et supprimable.

Le retour serveur pour recharger le datagrid quand on édite une ligne où on en supprime une, est trop long, sans compter le saut de page qui perturbe l'utilisateur.

Est-il possible de n'avoir un retour serveur que pour la ligne éditée ou supprimée ? Un peu à la manière d'un UpdatePanel...

Merci d'avance!

[Immobilis]

Salut,

Un peu à la manière d'un UpdatePanel

Et pourquoi ne mes-tu pas ta grille dans un UpdatePanel justement?

A+

[cyrano_de_bergerac]

Salut,Et pourquoi ne mes-tu pas ta grille dans un UpdatePanel justement?

Je l'ai fait, mais ça reste encore trop long, et même si je n'ai pas le saut de page proprement dit, j'ai un petit saut sur la grille.

[Immobilis]

Dis donc, tu ne serais pas en train de faire un double post avec ce fil http://www.developpez.net/forums/d13...leau-datagrid/ ? Ce n'est pas autorisé.

ça reste encore trop long

Le temps pour mettre une base de données à jour ne devrait pas être long.

Active la trace pour voir quelle étape du cycle de vie prend le plus de temps. Ainsi tu pourras isoler le problème et intervenir.

A+

[cyrano_de_bergerac]

Dans ce poste, je me focalise sur le datagrid, voir s'il y a une solution.
Dans l'autre poste, j'accepte de m'affranchir du datagrid, surtout depuis que mes recherches me disent que ça ne semble pas possible d'arriver à ce que je veux avec.
Bref, le but est le même mais les moyens divergent.

Il ne s'agit pas de mettre à jour une base de données, mais juste de pouvoir faire édition sur une ligne du datagrid, autrement dit aucun retour vers la BDD, mais un retour vers le serveur IIS qui me met la ligne en édition avec certaines spécificités.

[Immobilis]

autrement dit aucun retour vers la BDD, mais un retour vers le serveur IIS qui me met la ligne en édition avec certaines spécificités.

Tu peux préciser?

Une page web est stateless. Aucune existance sur le serveur web une fois envoyée au client. Si tu veux conserver un état de la ligne modifiée pour mettre la BDD à jour plus tard, tu vas devoir implémenter une logique de persistance (complexe). Cela ne me semble pas être une bonne idée sans savoir pourquoi tu as des problèmes de temps de réponse.

Active la trace pour voir quelle étape du cycle de vie prend le plus de temps. Ainsi tu pourras isoler le problème et intervenir.

A+

[cyrano_de_bergerac]

Une page web est stateless. Aucune existance sur le serveur web une fois envoyée au client. Si tu veux conserver un état de la ligne modifiée pour mettre la BDD à jour plus tard, tu vas devoir implémenter une logique de persistance (complexe). Cela ne me semble pas être une bonne idée sans savoir pourquoi tu as des problèmes de temps de réponse.

Je comprends bien.

Pour expliquer pas à pas ce que je veux faire:

Construction du tableau à partir du DataGrid avec OnItemDataBound="Grid_ItemDataBound":

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
protected void Grid_ItemDataBound(object sender, System.Web.UI.WebControls.DataGridItemEventArgs e)
{
        DataGridItem item = e.Item;
 
        if (item.ItemType == ListItemType.Item || item.ItemType == ListItemType.AlternatingItem)
        {
            CustomizeItem(item);
        }
        else if (item.ItemType == ListItemType.EditItem)
        {
            CustomizeEditItem(item);
        }
}
 
private void CustomizeItem(DataGridItem item) {...}
private void CustomizeEditItem(DataGridItem item) {...}

Quand je charge ma page pour la première fois, tout le tableau est construit avec le CustomizeItem.
Une fois que j'ai ma page avec mon tableau, si je clique sur le bouton "Edit", tout le tableau est construit avec le CustomizeItem sauf la ligne que j'édite qui est construite avec le CustomizeEditItem.
Bref ce qui prend du temps, c'est justement que je refais tout le tableau alors que seulement une ligne change sur ma page, à savoir la ligne qui passe en mode édition.
A noter qu'il y a 700 lignes dans mon tableau...

Merci en tout cas pour ton aide!

[Immobilis]

Tu affiches les 700 lignes??

[cyrano_de_bergerac]

Tu affiches les 700 lignes??

Oui, c'est un impératif de mon utilisateur, et je le comprends d'ailleurs pour le côté fonctionnel, car il s'agit de gérer des événements chronologiques dont chaque ligne est dépendante de la précédente.

[Immobilis]

Oui, c'est un impératif de mon utilisateur, et je le comprends d'ailleurs pour le côté fonctionnel, car il s'agit de gérer des événements chronologiques dont chaque ligne est dépendante de la précédente.

Ok, même si je ne comprend pas le besoin. Personne n'est capable de se servir (lire/modifier) de 700 lignes sur un écran... Enfin, ce n'est pas le sujet.

Cela dit, le gridview est tout sauf prévu pour afficher autant de lignes. Je serais curieux de savoir combien pèse ta page. Tu peux en sauvegarder une copie et me dire combien elle fait?

A mon avis tu devrais développer une page qui restitue le moins de code html possible. un repeater + jQuery (non intrusif) dans ce cas peut être une bonne solution. La machine du client va chauffer un peu mais bon...

Sinon, tu peux t'inspirer de ce site http://bonjourhamster.fr/archive. Seules quelques images sont visibles. Les suivantes apparaissent au fur et à mesure que tu scroll vers le bas.


A+

[cyrano_de_bergerac]

Cela dit, le gridview est tout sauf prévu pour afficher autant de lignes. Je serais curieux de savoir combien pèse ta page. Tu peux en sauvegarder une copie et me dire combien elle fait?

J'utilise un DataGrid et non un gridview, mais je pense que le problème d'affichage d'autant de lignes est le même.
J'ai fait File->Save As, et le fichier html sauvé pèse 1,795KB, si c'est bien comme ça qu'il fallait l'évaluer.

[Immobilis]

le fichier html sauvé pèse 1,795KB, si c'est bien comme ça qu'il fallait l'évaluer.

Oui, c'est bien cela. C'est beaucoup. Imagine qu'à chaque requête c'est cette masse qui circule sur le réseau. Pour peu que la personne ne soit pas "proche" du serveur le temps de transfer s'ajoute au temps de génération.

A ce propos, je t'avais demandé d'activer la trace. Quels sont les résultats? Y a-t-il des opération particulièrement longues?

Au final, tu n'as pas beaucoup de solutions avec ce composant... Soit tu renvois moins de données, soit tu acceptes le temps de latence.

A+

[cyrano_de_bergerac]

Oui, c'est bien cela. C'est beaucoup. Imagine qu'à chaque requête c'est cette masse qui circule sur le réseau. Pour peu que la personne ne soit pas "proche" du serveur le temps de transfer s'ajoute au temps de génération.

A ce propos, je t'avais demandé d'activer la trace. Quels sont les résultats? Y a-t-il des opération particulièrement longues?

Au final, tu n'as pas beaucoup de solutions avec ce composant... Soit tu renvois moins de données, soit tu acceptes le temps de latence.

A+

La personne est proche du réseau (réseau interne de l'entreprise), ce qui est déjà ça !

J'ai activé la trace. Tout va très vite : de la requête SQL jusqu'au dernier code exécuté côté serveur avant affichage de la page côté client.
Bref ça confirme que le poids de la page à afficher est ce qui prend du temps.
J'avoue ne pas avoir pensé à ça au départ, c'est la maturité informatique qui me manque (j'ai une formation prévue en septembre).

A noter que sous mozilla et chrome, tout fonctionne comme je le souhaiterai, et même mieux sous mozilla où je n'ai pas l'impression d'avoir de saut de page sur le datagrid (que j'ai encadré d'un UpdatePanel). Dommage que le logiciel officiel de mon entreprise soit IE.

Pour info, j'ai un prestataire qui m'avait codé la fabrication du tableau en html côté serveur, avec des fonctions javascripts pour faire les opérations nécessaires sur chaque ligne, mais le problème est que c'est immaintenable, et moche, d'où mon idée d'essayer de refaire fonctionner le datagrid.

Merci mille fois en tout cas pour ton aide !