The best explanation I've found for a postBack is from Wiki.
a postback is an HTTP POST to the same page that the form is on.
While the article does explain how a second page was needed in ASP, but no longer needed in ASP.NET, it doesn't give much detail or background. I am looking for a freakin' tome of information on PostBacks. Much like the simple question of "how can I clean a house" can be addressed by this 900 page book. I don't need 900 pages worth, but details please. I found a nice little tutorial for ASP.NET life cycle, but it seriously glosses over postbacks (amongst other things).
I am looking to the developers who have been around before .NET and really don't take these kinds of things for granted. Books and hyperlinks are reasonable answers or additions to your answer.
So far I've seen the right answer alluded to repeatedly, and almost everyone has come shy of what I consider subjectively to be the mark.
Let's start with the basics:
An HTTP request can be any of the HTTP verbs, but the two that people use most are GET and POST. Well, those are the two a programmer uses most frequently. The others all have some purpose, if they're implemented on the server. When you send information to the server, you can do so either through the use of the URL (to request a page) or within the body of the request (POST, PUT, DELETE, for instance).
Now you'll remark (I'm sure) that the URL in a GET request often contains data, and this is true, but according to W3C, you should not use GET to alter state, and yet we do often. It's sort of a hack that we all agree is an actual use, and not a hack. Whether that makes it a hack or an actual implementation detail I leave up to you.
So when you send the body of the POST (skipping the others for now, you can figure it out from here) with the form elements, you're sending back certain elements. How those elements are defined is up to you and to the environment you're working in. You could post to a server with a JSON element in the body, or with XML, or with form fields. Generally we do posts from a FORM element in the body of the HTML.
Now everyone says, "oh, a postback is a subsequent request to a page." But, that's not true. A postback is when you send data via POST -> back to the server. I say this because the difference between a GET request and a POST request is if data is included in the body (and the verb used, but the client usually knows how to deal with that). You could postback to the page on the first time the page is visited, and in fact ASP.NET has tools for doing that in the library. You could certainly have a desktop client POST data to a server (think Twitter) without showing any webpage at all from the server (ok, so twitter is probably not the best concept to use for an example here, but I want to illustrate that you can use a client that doesn't show the webpage, so no request is necessary).
So really what you should read there in "postback" is "I'm POSTing data BACK to the server for processing". It's presumed that you retrieved the page initially with a GET to show the user the <form> element that has <input> fields for them to interact with, and that at the end you're sending data back. But I hope you can see that it doesn't have to be in that order.
So here's something else to consider:
What if you gave the user a page with a bunch of <input>s and no <form> but instead, had a button wired up in javascript to concat all those <input>s with &value-n= and send them as a GET? Does the same thing, but violates that concept of only using GET for requests. (possibly) ensuing discussion encourages me to reinforce that GET should have no side effects (no updating values)
It's how come you can send someone a link to a google search, for instance. So we don't ALWAYS have to POST BACK to the server to get data.
Hope this helps.
Cheers
See ASP.NET Page Life Cycle Overview on MSDN for a good general introduction about what happens when a requests hits the server.
A PostBack is any request for a page that is not the first request. A PostBack will always be in response to a user action (triggered most commonly by a Button, AutoPostBack control or Ajax).
POSTBACK: Part of ASP.NET's contrived technique for hiding the true stateless nature of the web/HTTP behind a stateful facade. This results in complex code (IsPostback, ...), a hard to understand page lifecycle, many different events, ... and numerous problems (ViewState size, web-farm stickyness, state servers, browser warnings (not using PRG pattern), ...)
See ASP.NET MVC instead.
A post back is round trip from the client (Browser) to the server and then back to the client.
This enables you page to go through the asp engine on the server and any dynamic content to be updated.
here is a nice explanation
ASP.Net uses a new concept (well, new compared to asp... it's antiquated now) of ViewState to maintain the state of your asp.net controls. What does this mean? In a nutshell, if you type something into a textbox or select a dropdown from a dropdownlist, it will remember the values when you click on a button. Old asp would force you to write code to remember these values.
This is useful when if a user encounters an error. Instead of the programmer having to deal with remembering to re-populate each web control, the asp.net viewstate does this for you automatically. It's also useful because now the code behind can access the values of these controls on your asp.net web form with intellisense.
As for posting to the same page, yes, a "submit" button will post to an event handler on the code behind of the page. It's up to the event handler in the code behind to redirect to a different page if needs be (or serve up an error message to your page or whatever else you might need to do).
The Wikipedia definition of postback is pretty good, but I'd add the following:
A postback is a subsequent HTTP POST to the same page that the form is on.
If I have a page with a form on it and, rather than having my Submit button redirect the browser to another page that will process the form, instead have the Submit button refresh the current page (and perform some specific steps to validate/save the page, presumably), then that Submit button is said to have posted back to the current page.
Postbacks can be either full (refresh the entire page) or partial (in a case where AJAX is employed). A partial page postback will re-render only a part of the page (like a single drop-down list, a table, etc.).
In the old HTML, the only way to make something updated on the webpage is to resend a new webpage to the client browser. That's what ASP used to do, you have to do this thing call a "PostBack" to send an updated page to the client.
In ASP .NET, you don't have to resend the entire webpage. You can now use AJAX, or other ASP.NET controls such that you don't have to resend the entire webpage.
If you visit some old website, you would notice that once you click something, the entire page has to be refresh, this is the old ASP. In most of the modern website, you will notice your browser doesn't have to refresh the entire page, it only updates the part of the content that needs to be updated. For example, in Stackoverflow, you see the page update only the content, not the entire webpage.
Simply put this by a little code. Hope it is helpful to you.
When you firstly request the page url. you can view the source code of it in most browser. Below is a sample of it .
The essential of Post Back is actually call the __doPostBack which submit all the form data got from your firstly requested back to the server. (__EVENTTARGET contains the id of the control.)
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>
NHibernate Demo
</title>
<script language="javascript" type="text/javascript">
function dopost() {
__doPostBack('LinkButton1', '');
}
</script>
</head>
<body>
<h1>NHibernate Demo</h1>
<form name="ctl01" method="post" action="Default.aspx" id="ctl01">
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTMxNzcwNTYyMWRkKHoXAC3dty39nROvcj1ZHqZ5FYY=" />
</div>
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['ctl01'];
if (!theForm) {
theForm = document.ctl01;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
//]]>
</script>
<div>
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="B2D7F301" />
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKZx5vTCgKM54rGBgLM9PumD20dn9KQguomfpAOdTG0r9Psa7al" />
</div>
<a id="LinkButton1" href="javascript:__doPostBack('LinkButton1','')">LinkButton</a>
<input type="button" value="testPostBack" id="testpostback" onclick="dopost();" />
</form>
</body>
</html>
Postback is a request during which ASP restores values of controls' properties from view state.
Related
When a client is on page A.aspx , and he press some button there is a postback.
The server knows which page to rebuild according to the request.
but how does the client knows which page to re-ask ? by the current url of his browser ?
where this information is saved in the client side ?
Its defined in the action property of <form>. The client does not need to re-ask, the server sends a response of his request.
ASP.NET is just a part of the .NET framework, but what every client sees on a web browser in plain old HTML.
ASP.NET gives you several controls that makes it easy to use them programatically, so we can set all sort of things in our code (that is run before the page is showing) to do the exactly what we want.
every link, button, image, grid, it's just HTML tags, like <a> for links, <input type="button"> for buttons etc...
Keep in mind that now, there are 2 variantes of the ASP.NET, the WebForms and the MVC (you can also read about choosing one in prole of the other)
in every ASP.NET WebForms there is always a <form> on the start of the <body> and wrapps all your code, so, any submit will do a PostBack into the same file name, in your example A.apsx will always post into A.aspx, then if you want, for example, send that request to B.aspx you need to have a Click Event that would use the Server.Transfer("B.aspx") and that would redirect the entire post to B.aspx just like it was a post from B.aspx
in the newest pattern, the ASP.NET MVC, it drives with Routes witch let's you set up any, every, one, multiple, ways to reach the same page. In MVC the URL does not point to a specific page, but to a specific Controller and it's up to the Controller to send, after processing the data, to a specific View, that is why in MVC there are no pages in the url (though you can add it to the route if you want, and you can accomplish the same with WebForms using a Routing plugin).
Now, in MVC it's there is no <form> wrapping up your entire code, you need to, if you want to submit something, create your own <form> and point to the correct route
but, just like in Webforms or any HTML page, posts are made through form submittion, and it's "path" it's always whats in the form attribute action that let's you know what's the next step.
I hope this helps you realizing that there is no big monster in ASP.NET, that is only a way to reuse controls and access them programmatically and that, in the end, it's all HTML :)
A general answer: on the client side it's either a submit from within a form or a link.
The form points to either a relative URL (that means the current URL plays a key role) or an absolute URL (the current URL plays little to no role).
For links it's generally the same: either they are relative or absolute. One big difference: links are use HTTP GET while forms can use HTTP POST (thus transferring more data without encoding them to the URL as parameters).
For a button it's the form that gets submitted.
The goal is to popup an asp.net page from classic asp using post data, however, the asp.net page always has Request.Form variables as empty and shows RequestType get.
I have stripped all the code from asp out, tested receiving the form variables sent from an html page on the asp.net page and this works fine. Copying the same form html to the asp page still gives no request.form data and a RequestType get
<html>
<head></head>
<body>
<form method="post" name="form" action="http://localhost:51307">
<input name="uid" value="1" />
<input type="submit" name="Submit" />
</form>
</body>
The asp site is using frames and the form is sent from a child frame, I'm unsure if this is the issue.
2.
Assuming this worked, I had thought to submit a form in asp and use the onsubmit event of the form to popup the page which would send the form variables as post data. Is this the best way of doing this?
UPDATE
The frames seem to be at fault here somehow, I have posted from the form within the framed page to another classic asp page and then redirected from this to the asp.net page.
This probably happened because "Navigate windows and frames across different domains" is disabled by default in IE browsers, which means you can't pass form data due to security reasons.
ASP.NET requires certain form fields to be set (usually as hidden fields, though HTTP POST obviously does not know the difference) for an inbound request to be treated as valid, thereby populating the relevant variables.
If I recall, you need to set __EVENTTARGET, __EVENTARGUMENT, and __VIEWSTATE.
Then, your ASP.NET code needs to be able to handle what was sent, as the default handlers will expect there to be something in __VIEWSTATE at a minimum. So, you would need to override the ViewState handler in your page. I can update with more information later when I'm at work, since I know I've done this before.
The problem is with the redirect. When you redirect a page, it creates a GET request instead of a POST request, and therefore will not have any form data.
Your options are to :
Append the form values to the query string.
Dynamically generate the form corresponding to the posted Request.Form collection, and submit it to the ASP.NET page using Javascript during the body onload event.
what is difference between server side submitting and client side submitting a form.
Can any one explain with an example.
Thank you
There's no such thing as server-side form posting. (unless of course you have server side code that creates web requests to a different web site and post data there and then reads responses, but based on your question I seriously doubt this is the case)
There are however two types of client-side form postings:
the old-fashioned way by having a FORM element with INPUT elements and a submit button (either an INPUT TYPE="submit" or a BUTTON TYPE="submit");
<form method="post" action="some URL that will receive posted data">
<input type="text" name="UserName" />
...
<button type="submit>Save</button>
</form>
the new often user-friendlier Ajax posting that doesn't require any particular elements at all; there probably will be for users to enter some data, but sometimes they don't exist at all; example uses jQuery to simplify Ajax posting;
$.ajax({
url: "some URL that will get posted data"
data: { UserName: "JohnDoe" }
type: "POST",
success: function(data, status, xhr){
// do what's required
},
error: function(xhr, status, err){
// inform the user about an error
}
});
The first one has the nasty page loading/refresh/redraw side effect that makes it harder to keep scroll position etc.
The second one relies heavily on Javascript and manipulating DOM elements with results.
If I understand your query, I think you are asking about ways of submitting of a form from a client/browser.
a) In plain HTML, you need to explicitly specify the Javascript function to do the form posting in the form element
<form id="form1" onsubmit="JavascriptFunction();" .....>
b) When using ASP.NET framework, you don't have to worry about form posting from the browser, as ASP.NET does this automatically for you. Instead the .aspx pages postback to themselves.
If you need further clarification, let us know
We have a user who is having problems with a ASP.NET app. The user hasn't been available to gather many details, but at this point our best guess is that the PostBack is not occurring. Something is going wrong between when the user clicks the LinkButton and when the HTTP Request is supposed to be made.
(User does have JS enabled)
Beyond solving the immediate problem, it might be helpful for posterity to assemble the canonical list of things that can break PostBack behavior of ASP.NET controls.
If you have say a button that has a postback event as well as a javascript event on click, if the javascript event that is fired returns false postback will be stopped.
I would first check that your <form> tags are well formed and that you don't have nested <form> tags. Both times I've debugged something to do with postback this turned out to be the problem. It's confusing because it's a browser dependent issue.
Having a self-closing <script /> tag can stop postbacks occurring. Get the user to send you any javascript errors from their log. There is actually a decent JS debugger in IE8 (about the only good thing in it!).
a form with no method attribute, or method note being set to POST
an onsubmit event handler that does not return true
trying to submit the form programatically, but unable to locate the form by id as there is another element with the same id on the page
Scenario:
The task I have at hand is to enable a single-signon solution between different organizations/websites. I start as an authenticated user on one organization's website, convert specific information into an Xml document, encrypt the document with triple des, and send that over as a post variable to the second organizations login page.
Question:
Once I have my xml data packaged, how do I programmatically perform a post to the second website and have the user's browser redirected to the second website as well.
This should behave just like having a form like:
action="http://www.www.com/posthere" method="post"
... and having a hidden text field like:
input type="hidden" value="my encrypted xml"
This is being written in asp.net 2.0 webforms.
--
Edit: Nic asks why the html form I describe above will not work. Answer: I have no control over either site; I am building the "middle man" that makes all of this happen. Site 1 is forwarding a user to the page that I am making, I have to build the XML, and then forward it to site 2. Site 1 does not want the user to know about my site, the redirect should be transparent.
The process I have described above is what both parties (site A and site B) mandate.
Send back a document that contains the from with hidden input and include an onload handler that posts the form immediately to the other site. Using jquery's document.ready() solves the issue of whether the DOM is loaded before the post occurs, though there are other ways to do this without jquery. You might want to include some small message on the screen to the effect that the user will be redirected shortly and provide a link which also does the post
...headers left out...
<script type='text/javascript'>
$(document).ready( function() {
$('form:first').submit();
});
</script>
<body>
<form action='othersiteurl' method='POST'>
<input type='hidden' value='your-encrypted-xml" />
</form>
</body>
You are thinking about this too process oriented, it would take you a month of sundays to try and work out all the bugs and moving parts with what you suggest.
You are already doing a post to another server so you really don't need to do anything. The form you have is already perfect, and when the other server intercepts the request that is when it makes the decision to either allow to user in and continue in through the site, or redirect them back to their Referer (sic) in the header. When redirecting back to the Referer they may want to tack on a message that says what was wrong, such as ?error=no_auth
I wrote on this for another question a while back. Hope this helps:
How do you pass an authenticaticated session between app domains