Pour ce faire, il faut généralement créer un formulaire web aspx qui utilise la chaîne de recherche pour indiquer quel enregistrement charger/traiter.
Disons que vous avez une page qui vous permet de mettre à jour certaines informations sur les clients :
http://www.mysite.com/customer.aspx
Vous devez charger le formulaire en utilisant un identifiant dans la chaîne de requête :
http://www.mysite.com/customer.aspx?CustomerId=42
Dans le code de base, vous auriez quelque chose comme ceci :
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
int customerId = 0;
if (!string.IsNullOrEmpty(Request.QueryString["CustomerId"]))
{
int.TryParse(Request.QueryString["CustomerId"], out customerId );
}
if (customerId == 0)
{
//handle case when no valid customer id was passed in the qs here
}
else
{
//load customer details, bind controls etc
//make sure to handle the case when no customer was found using the id in the qs
}
}
}
Ensuite, quelque part dans votre page, vous devez avoir un bouton qui enregistre les modifications. Ce bouton aurait un gestionnaire OnClick dans le code sous-jacent :
protected void SaveClicked(object sender, EventArgs e)
{
//save changes to database here
//Redirect if all went well
Response.Redirect("http://www.mysite.com/customer.aspx?CustomerId="
+ idOfSavedCustomer.ToString());
}
Ça devrait être tout. La redirection fera en sorte que le navigateur émette une nouvelle requête GET pour l'url dans la Redirect(...). Il chargera la page, le if (!IsPostBack) va s'exécuter et initialiser la page avec les nouvelles valeurs que vous venez de sauvegarder dans le post précédent.
Pour l'ensemble de ce processus, le trafic entre le navigateur et le serveur ressemblerait à ceci :
Browser: GET http://www.mysite.com/customer.aspx?CustomerId=42
Server: 200 (send back some html)
Browser: POST http://www.mysite.com/customer.aspx?CustomerId=42 (post data sent in request)
Server: 302 (point to http://www.mysite.com/customer.aspx?CustomerId=42)
Browser: GET http://www.mysite.com/customer.aspx?CustomerId=42
Server: 200 (send html)
Dans l'étape intermédiaire, le serveur dit en gros :
"Cette demande de poste que vous m'avez envoyée, j'en ai fini avec ça. Maintenant, s'il vous plaît obtenu à cette autre page ici ... "
Le fait que l'url renvoie en fait à la même page n'est pas important.
Quelques réflexions en réponse à votre liste de questions :
- comment peut-on effectuer un POST à un endroit qui n'est pas sa forme originale ?
Vous pouvez le faire en définissant l'option action sur le formulaire, ou vous pouvez définir l'attribut PostBackUrl sur le bouton.
- Que devient le ViewState lorsque vous publiez sur un formulaire qui ne lit pas l'état de la vue ? l'état de la vue ?
Cela dépend. Si vous postez simplement le formulaire sur une autre page, vous pouvez utiliser la directive <%@ PreviousPageType .../> pour indiquer à la "nouvelle" page d'où provient le post. Cela simplifiera le travail avec les données postées sur la nouvelle page. Voir ce lien pour plus de détails .
- que devient le ViewState lorsque l'on redirige vers le "vrai" formulaire aspx ?
L'état de la vue est envoyé dans la demande de poste. Lors de la redirection, le navigateur chargera une nouvelle page et créera son propre état d'affichage.
- ViewState est-il fondamentalement incompatible avec ASP.net ? Post-Redirect-Get ?
Ça dépend de la façon dont on voit les choses. Après la redirection, la nouvelle page n'aura pas accès à l'état d'affichage de la page précédente.
- ASP.net est-il fondamentalement incompatible avec Post-Redirect--Get ?
Non. Voir l'exemple ci-dessus.
- comment (i.e. quel code) redirigez-vous vers le "vrai" formulaire web aspx ?
Response.Redirect(url). Cela enverra une réponse au navigateur, lui indiquant d'effectuer une nouvelle demande d'accès.
- quand (c'est-à-dire dans quel gestionnaire d'événement) redirigez-vous vers le "vrai" formulaire web aspx ?
Lorsque vous avez effectué tout le travail nécessaire pour traiter la demande de poste.
- les questions connexes soulèvent le problème de l'affichage des données du formulaire. Le site l'implication que les formulaires HTML ne peuvent pas être utilisés - et toutes les données de formulaire doivent être ajoutées à la chaîne d'interrogation. Cela est-il vrai ? Si oui, pourquoi ? Si non, pourquoi ? pourquoi pas ? Un navigateur peut-il mettre des données de formulaire dans une chaîne d'interrogation ?
La redirection d'une requête post n'est pas bien supportée et devrait probablement être évitée. Cela peut être fait (avec certains navigateurs) en utilisant la réponse http 307. En faisant cela, le serveur indique effectivement au navigateur que " Je ne traiterai pas votre demande de poste, veuillez la poster sur cette autre page à la place. ".
- une question connexe mentionne Server.Transfer. L'utilisation de Server.Transfer est complètement erronée, et ne résout en aucun cas le problème de Post-Redirect-Get (car il n'y a pas de redirection). Est-ce exact ?
Server.Transfer(...) est un processus qui se déroule du côté du serveur. Le navigateur n'en est pas conscient. En fait, une page peut utiliser Server.Transfer pour demander à une autre page d'effectuer un traitement, et cette page sera chargée de renvoyer une réponse au navigateur. Mais le navigateur pensera que c'est la page originale qui a répondu.
- quel changement de code doit être effectué dans le fichier aspx ou aspx.cs pour prendre en charge PRG ? On peut supposer qu'il faut au moins modifier le code pour qu'il s'affiche ailleurs que dans MyPage.aspx. ailleurs que dans MyPage.aspx.
Non, un post back normal peut être utilisé. L'astuce consiste à avoir un (ou plusieurs) gestionnaire(s) d'événement spécifique(s) sur la page qui effectue un Repsonse.Redirect après avoir traité les données postées.
