2010-03-04 14 views
1

Probablement une question débutant très élémentaire.Restauration de l'ancienne valeur d'une zone de texte (ou de tout autre contrôle)

Imaginez la situation suivante:

J'ai une page ASP.NET avec une zone de texte et un bouton. Dans la zone de texte, je vais dire un nom "Laurel" et cliquez sur le bouton. La zone de texte est liée comme un paramètre de contrôle à une source de données et cette source de données extrait le contenu "Laurel" de la zone de texte pour créer une requête, sélectionne toutes les commandes du client Laurel et les renvoie au navigateur où elles sont affichées dans une liste (gridview par exemple). La liste est longue et a deux pages (la liste a un contrôle de pager). La liste est sur la même page où se trouve également la zone de texte. Donc, je vois maintenant une page dans mon navigateur avec la zone de texte (contenant toujours le texte "Laurel") et une liste avec un pager.

que je pouvais faire maintenant deux actions:

  • Entrez le nom de « Hardy » dans la zone de texte et cliquez sur le bouton: Le cycle passe au-dessus encore et les commandes de client Hardy sont affichés. C'est bien et ce que je veux.
  • Cliquez sur le contrôle pager pour afficher la deuxième page des commandes de Laurel. Cela fonctionne parce que j'ai toujours "Laurel" dans la zone de texte. Ainsi, sur la publication déclenchée par le contrôle du téléavertisseur, la source de données peut à nouveau extraire "Laurel" comme paramètre de requête de la zone de texte, exécuter la requête et transmettre la deuxième page de commandes à mon navigateur. C'est bien aussi.

En fait, il pourrait y avoir une troisième action:

  • J'entre le nom « Hardy » dans la zone de texte, puis changer mon esprit et décider que je veux voir la deuxième page de l'ordre de Laurel. J'ai donc "Hardy" dans la zone de texte mais ne cliquez pas sur le bouton soumettre mais je clique sur "page suivante" du contrôle pager pour voir la deuxième page. Sur le serveur, la source de données extrait le contenu "Hardy" de la zone de texte, lance une requête et tente ensuite de livrer la deuxième page de Hardy au lieu des commandes de Laurel. Donc ce n'est pas ce que je veux. (Peut-être que Hardy a seulement quelques ordres, pas assez pour deux pages.La source de données pourrait me dire alors "Rien trouvé" parce qu'il n'y a rien sur la deuxième page pour Hardy.)

(Ce que je veux dire peut aussi être vu ici sur stackoverflow: Entrez quelque chose dans la boîte de recherche, par exemple "ASP.NET" et appuyez sur la touche Entrée, vous obtiendrez une longue liste de résultats avec beaucoup de pages puis entrez un autre terme dans la boîte de recherche, par exemple "PHP "mais ne frappez pas entrer, cliquez sur la page 2 dans le contrôle pager en bas de la page.Une publication se produit (qui transmet également le nouveau contenu" PHP "de la boîte de recherche, je suppose), la deuxième page pour mot clé" ASP.NET "est affiché et la boîte de recherche ne contient plus" PHP "mais plutôt" ASP.NET ".)

La question est maintenant: Comment puis-je éviter une situation comme celle-ci? Mon idée de base est: je dois restaurer l'ancienne valeur "Laurel" dans la zone de texte pour fournir la valeur de paramètre correcte à la requête de source de données et mon ancienne valeur "Laurel" doit être stockée "quelque part" (sur serveur? sur client? si sur client, caché dans la page ou dans un cookie ou ...?). Existe-t-il des modèles standard pour répondre à cette exigence? Ou est-ce que je pense dans la mauvaise direction?

Merci d'avance!

Répondre

1

Comme vous l'avez mentionné dans votre question, il vous suffit de stocker le terme de recherche actuel quelque part et de le mettre à jour uniquement lorsque vous cliquez sur le bouton Rechercher.Il y a beaucoup d'options:

  • l'objet Session
  • l'objet ViewState
  • comme QueryString sur l'URL
  • un champ caché sur la page

La plupart des débutants choisiraient la session objet, car c'est le plus simple, mais il est également discutable car Session est partagée entre les pages et vous avez affaire à des données qui se rapportent à une seule page. Par conséquent, l'une des autres options serait meilleure, du point de vue des normes.

+0

Merci pour vos commentaires! Je viens de voir que stackoverflow semble utiliser QueryStrings pour stocker le terme de recherche. Je comprends la solution pour utiliser l'objet de session et un champ caché. Cependant, je ne suis pas sûr de savoir comment travailler avec l'objet ViewState. Jusqu'à présent, pour moi, c'était toujours un instrument utilisé en interne par ASP.NET pour la gestion d'état, rien n'était destiné à être utilisé par programmation. Je dois en savoir plus sur ViewState. L'utilisation de l'objet de session requiert que les cookies soient acceptés dans le navigateur client, est-ce correct? – Slauma

+0

L'accès ViewState et Session est codé de manière identique - voir http://stackoverflow.com/questions/944484/syntax-to-access-variables-in-viewstate. Normalement, l'utilisation de la session nécessite un cookie, mais vous pouvez configurer des sessions sans cookie, où l'ID est transmis dans le cadre de l'URL. (http://stackoverflow.com/questions/2273066/what-are-cookieless-sessions) –

1

Vous pourriez peut-être essayer de stocker votre terme de recherche dans ViewState lorsque le formulaire est soumis:

private void submitBtn_Click(object sender, EventArgs e) { 
    ... 
    ViewState["query"] = search.Text; 
    ... 
} 

vérifier ensuite pour cette ViewState postback et mis sur la propriété search.Text:

private void Page_Load(object sender, EventArgs e) { 
    ... 
    if (!IsPostBack) { 
     ... 
    } else { 
     ... 
     if (ViewState["query"] != null) { 
      search.Text = ViewState["query"].ToString(); 
     } 
     ... 
    } 
    ... 
} 

(Stack Overflow est construit avec ASP.NET MVC, donc il n'a pas à gérer les postbacks: à la place, le formulaire de recherche utilise HTTP GET, c'est pourquoi vous verrez les termes de recherche dans la chaîne de requête. si le terme de recherche existe dans la chaîne de requête et le lien de pagination s sera probablement construit d'une manière similaire, d'où la raison pour laquelle vous pouvez changer le champ de saisie, pas soumettre le formulaire mais toujours voir page 2, 3, etc. de votre requête originale).

+0

Merci pour votre réponse! J'avais commencé à coder quelque chose de très similaire à votre exemple de code, mais j'étais inquiet si je suivais le bon chemin. Cependant, dans mon code j'avais utilisé 'Session' au lieu de' ViewState'. Jason Berkan dans une autre réponse ici a déjà expliqué que l'accès ViewState et Session sont codés de manière identique. Mais quelle est alors la différence? Est-ce que ViewState a un avantage sur Session? – Slauma

+0

Le code ci-dessus a en fait un problème avec la séquence d'événements de page: Chargement se produit avant que Click, écrasant ainsi le texte entré dans la zone de texte, également dans le cas où le bouton est effectivement cliqué. J'ai résolu ceci avec une variable privée, en le définissant à TextBox.Text au début de Page_Load, puis en l'écrivant à TextBox.Text au début du gestionnaire d'événements click. – Slauma

+1

@Slauma ViewState conserve les données à travers les publications, tandis que la session dure toute la durée de la visite d'un utilisateur sur un site (à moins que le temps ne soit trop long). –

Questions connexes