Quand une publication n'est-elle pas une publication? (selon ASP.net)

Question

Y at-il une différence entre moi en utilisant Javascript pour rediriger vers URL + "? Querystring = valeur" par rapport à l'aide de tout mécanisme utilisé par ASP.NET?

En cas de différence, comment puis-je soumettre la page ASP.NET rendue à la même URL avec une chaîne de requête différente par javascript?

Answer 1

Si vous veulent faire un post en arrière comme un contrôle asp comme un asp:Button vous pouvez utiliser les fonctions javascript inclus par le cadre de le faire:

__doPostBack('ControlIDOfEventYouWantToRaise',''); 

vous pouvez en lire plus abo ut l'__doPostBack dans cet article:

Doing or Raising Postback using __doPostBack() function from Javascript in Asp.Net

Il suffit de faire un form.submit() ne sera pas exactement la même que l'utilisation __doPostBack.

Pour répondre à la première partie de votre question, il n'y a aucune différence à faire une redirection si vous faites juste un Response.Redirect comme le fera un GET. La différence est que si vous utilisez un contrôle asp:Button par exemple, il accédera d'abord à votre page pour gérer le bouton (un post de retour), puis fera un GET sur la page redirigée.

Si vous souhaitez soumettre à la même URL (par exemple publier vos données), alors vous devez utiliser la méthode __doPostBack. Si vous n'avez pas besoin que les données soient publiées, faites simplement une redirection en javascript vers la même URL avec une chaîne de requête modifiée (qui fera juste une base GET) mais vos données ne seront pas publiées.

Answer 2

La seule différence de potentiel est qu'un paramètre querystring est envoyé via GET, une forme est (habituellement) envoyée par POST.

GET a une beaucoup plus petite limite de données que les navigateurs ont une longueur d'URL max (il varie)

Vous pourrait utiliser javascript pour faire une form.submit() qui Shoul émule ce ASP.Net ne

Answer 3

Je ne suis pas d'accord avec la réponse de Basiclife; si vous avez un code à l'intérieur quelque chose comme

if (IsPostBack) { 

il ne va pas être équivalent, à savoir le code va être exécuté si vous configurez simplement l'URL. En outre, les contrôles conservent leur état à travers les publications, mais sont fraîchement initialisés si vous appelez à nouveau l'URL. Cela est dû au fait qu'ASP.NET essaye d'émuler une application "normale", donc la façon de s'assurer qu'un appel normal et un postback ont ​​le même effet peut résulter en "dé-ASP.NET-ing" de la page entière.

Je ne sais pas si ce que vous voulez fonctionne. Il y a probablement un moyen. Mais je soupçonne fortement qu'il existe une meilleure façon de le faire. Si vous obtenez une publication gratuite et que vous pouvez transmettre des données, pourquoi est-il crucial que les données apparaissent dans l'URL, au lieu d'être affichées facilement? Je peux voir comment vous voulez qu'une page réagisse à un paramètre d'URL, et comment vous voudrez peut-être changer le même paramètre ultérieurement en fonction de ce qui se passe sur cette page, mais comme vous savez toujours que vous revenez, vous pouvez par exemple remplacer ce paramètre d'URL dans ce cas, par quelque chose que vous publiez en arrière. Cela ne sonne pas donc bien, mais il pourrait effectivement être moins salissant. D'autant plus que vous semblez avoir une raison de ne pas abandonner la publication (sinon vous pourriez simplement utiliser un lien, non?).