2009-05-28 8 views
4

Donc, je comprends les bases du modèle prg. Mais je ne suis pas tombé sur une technique pour rendre des données arbitraires disponibles à l'instance "get" d'une page. Par exemple, je pourrais vouloir afficher différents messages de retour à l'utilisateur en fonction de leur action qui a initié le PostBack.Comment implémenter le modèle Post/Redirect/Get dans asp.net WebForms?

Ce que j'ai fait est d'envoyer un identifiant en tant que paramètre de chaîne de requête. Cela fonctionne bien, mais il introduit des problèmes de bookmarking et ne semble pas très bien évoluer. Et si j'avais besoin d'envoyer tout ViewState?

Malheureusement, je suis actuellement lié à WebForms et je n'ai pas réussi à convaincre mon organisation de migrer vers mvc.

Répondre

3

Si les champs POSTée sont persistaient Avant la redirection et vous devez accéder à ces données après la redirection, j'ajouterais l'identificateur pour les enregistrements de données sur la chaîne de requête que vous mentionnez. Vous pouvez également spécifier un statut pour la demande (pour l'affichage des messages, etc.). Ensuite, sur la page GET, vous pouvez lire les données et faire ce que vous voulez.

Je ne vois pas d'autre moyen de contourner ce que chaque page obtenue par GET ne sera pas avoir accès à la page précédente de ViewState etc.

L'utilisation Server.Transfer aura le même effet que la manipulation du POST sur la page originale.

Vous pouvez utiliser des variables de session pour stocker les données POST, mais cela pue.

+0

Ouais, je réalise que l'information devra être conservée. Je suis à la recherche d'une manière optimale de mettre en œuvre cela. Si je comprends bien, Server.Transfer contourne la partie "Redirect" de prg. –

+0

Les seules options qui me viennent à l'esprit pour implémenter la persistance dans ce scénario seraient de stocker/récupérer les données dans une base de données ou un fichier, ou de stocker les données dans l'objet Session.Vous pouvez stocker un objet pour représenter les données dans le POST, bien que le stockage de types primitifs dans Session soit probablement plus efficace. –

0

Je pense que vous pouvez toujours utiliser la méthode get dans l'élément de formulaire. Dans ce cas, vous ne pourrez pas utiliser l'ID de votre contrôle normalement. Mais vous pouvez utiliser la collection Request.Params pour obtenir viewstate.

Mise à jour: Désolé, je viens d'essayer à nouveau. et trouvé que vous pouvez accéder à votre contrôle serveur par son ID dans codebehind. comme:

Response.Write(text1.Text) 

voir l'exemple:

la page ASPX (seul l'élément de forme):

< form id="form1" runat="server" method="get"> 
< div> 
< asp:TextBox ID="text1" runat="server" /> 
< asp:Button ID="button1" runat="server" OnClick="buttonClick" /> 
< div> 
< form> 

REMARQUE: je un espace avant chaque "<" sinon la le code ci-dessus ne sera pas visible.

le code behind (uniquement le bouton événement click):

protected void buttonClick(object sender, EventArgs e) 
    { 
     string text = Request.Params["text1"]; 

     Response.Write(text); 
    } 

lorsque vous cliquez sur le bouton l'URL ressemblera à ceci:

http://localhost:1157/WebSite1/Default.aspx?__VIEWSTATE=%2FwEPDwUKMTkwNjc4NTIwMWRkoJEtEHZ8lHQ53QllSkz8ncpEw80%3D&__EVENTVALIDATION=%2FwEWAwKf%2BPPUCwKTjKGwCgKs34rGBvus9oxN%2FQkHlkzpKUEwrbxHLM6u&text1=ashish&button1=

+0

Il y a des limites sur la taille de la chaîne de requête, environ 2kb. Le viewstate sera presque toujours plus grand que ça. – GlennG

Questions connexes