i've been asked this question and id not know the answer.
Thanks for any help!
Postback is a term used often in ASP.NET when a WebForm POSTs the single form back to the server and invokes some event in the code behind (like a click on a button for example). You could still use normal GET requests though to redirect to a given web page. For example you could use an anchor:
Go to page 2
When the user clicks on the anchor there is no postback occuring but a GET request to the target web page.
Another possibility is the user typing directly the address of the web page in his browser address bar.
Yet another possibility is to use javascript to perform an AJAX request which allows to invoke a web page without redirecting away from the current page. You could use any HTTP verb with AJAX.
We can use javascript code to do some function without postback. This will save the time for the request and response to the server. But this client side. you can't reach the server without posting back.But my mean you can do functionality by javascript which does not postback the page.
Hope it may help.
If you like to categories the call to the server you can say that there are two types.
The GET and the POST
The POST is the post back and are the parameters that you send using a form
and the GET that are the parameters that you can send from the url.
More about:
http://www.cs.tut.fi/~jkorpela/forms/methods.html
http://thinkvitamin.com/code/the-definitive-guide-to-get-vs-post/
http://catcode.com/formguide/getpost.html
but I think the interview question was about the Ajax call, and this is probably what they try to see if you know, how to use Ajax to reach the server with javascript and not make postback. But you need to know that Ajax can make POST back, but this is done with out leave the page, with out make a full page post back.
Related
Can someone point me to a link which explains difference between IsPostBack, IsCallback and IsCrossPagePostBack in ASP.NET?
I have googled but didn’t get exact information.
Found below link for difference between IsPostBack, IsCallback.
What is the difference between Page.IsPostBack and Page.IsCallBack?
Thanks,
Balu
1) IsPostBack: "A postback is a request sent from a client to server from the same page, user is already working with." ASP.NET was introduced with a mechanism to post an HTTP POST request back to the same page. It’s basically posting a complete page back to server (i.e. sending all of its data) on same page. So, the whole page is refreshed.
2) IsCallBack: “A callback is generally a call for execution of a function after another function has completed.” But if we try to differentiate it from a postback then we can say: It’s a call made to the server to receive specific data instead of whole page refresh like a postback. In ASP.NET, its achieved using AJAX, that makes a call to server and updating a part of the page with specific data received.
3) IsCrossPagePostBack: “Gets a value indicating whether the page is involved in a cross-page postback or not." It's a different feature from "IsPostBack" and "IsCalBack" because It's generally used when we need to get the data from previous page
Reference Link
I've put some objects in an S3 bucket and I want to log everytime a client makes a request to one of those objects.
I'm using Umbraco 4.8 as my back-end with some custom code running.
The solutions I've come up with:
Set the link to an ASP page that pulls the object from S3 and sends it back as the response. The problem I see there is then the client has to wait for ASP to load the file before it can begin downloading the file.
Set the link to an ASP page that logs the request and returns a Response.Redirect to the S3 object. To me this seems like an unnecessary redirect and the client might cache that redirect and not hit my server the next time they access that object.
Does anyone have any other solutions or thoughts on how to achieve this? Any help would be appreciated.
I would use jquery and google analytics. Add a class to each link that you want to track and then use jquery to manipulate the onclick event to something like:
link text
Replacing the three variables appropriately ('s3-Bucket-Request', 's3-actual-bucket-name', 'current-page'). If you then put the jquery at the head of each page you have a reusable function.
start:
link text
jquery:
$('.ga').attr("onclick", "__gaq.push(['_trackEvent', 's3-Bucket-Request', 's3-actual-bucket-name', 'current-page']);");
end:
link text
Depending on how accurate you need this to be, you could also do it client side. Using jQuery, etc, add a click handler to a href tags that makes an ajax request to a controller, logging the activity.
Is there a way to crawl some ASP.NET pages that uses doPostBack as events calling?
Example:
Page1.aspx:
Contains 1 LinkButton that redirects to Page2.aspx
Code-behind for LinkButton Click event:
Response.Redirect("Page2.aspx")
In client side this code is generated on click event:
doPostBack(...
Is it possible crawl pages using only HttpWebRequest?
I know that use Response.Redirect is not a good idea in this case, but I don't have choice.
Yes, it's possible if the code follows a well predictable pattern. You would have to gather the form data from the page and simulate what the doPostBack function does (putting some values in some hidden fields), and send a POST request to the server. What you get back would be a redirection page, so you would have to parse that to get the url of the target page.
If you mean if search engines like Google will crawl the pages, then that is very unlikely. They might attempt to follow some common patterns of posting and script linking, but generally you need to use proper links between the pages to be sure that they are crawlable.
I have an asp.net application that runs exclusively on IE7 (internal web site).
When a user needs to enter data, I pop up a child window with a form. When the form closes, it calls javascript:window.opener.location.reload(true) so that the new data will display on the main page.
The problem is that the browser complains that it must repost the page. Is there any way to turn this feature off?
No, but there is a solution. Its generally considered good design to use a 302 redirect immediately after someone posts data to a page. This prevents that popup from ever occuring. Allow me to elaborate.
1) The user fills in a form and submits data via POST.
2) The backend receives the data and acts upon it.
3) Instead of returning the content to the user, the backend issues a 302 redirect as soon as its done processing the page (possibly redirecting the user back to the exact same url, if need be)
4) The page that the user will see is the page you told their browser to redirect to. They will load up the redirected page with a standard GET request. If they try to refresh the page, it will not repost the data. Problem solved.
This is a problem with the usual "postback" way of ASP.NET. If you need to reload a page without this warning, this page must come from a GET, not a POST. You could do a Response.Redirect("...") yourself. But this will destroy the use of viewstate.
asp.net mvc fixes this issue, not an ie7 only problem but a security feature of most browsers. No fix that I know of except you could just update the content in the main form with js rather than reloading the whole page
It's because the page in window.opener comes from a POST Request
Maybe you can use
javascript:window.opener.location = window.opener.location; to do just a GET request if the data can be fetched without a POST.
I do not believe that there is a way to do that. Instead, why not direct the parent window to a page without a reload.
javascript:window.opener.location='your url'
AFAIK, not via your scripts.
You might try:
window.opener.location = '#';
It should circumvent the browser reposting. And, you can adjust the hash name as needed.
If you move from page1 to page2, and want to disable the browser from going back to page 1,then add the following at the top of page1.
<script>
if(window.history.forward(1) != null)
window.history.forward(1);
</script>
Or vice versa.
Update:
Hmm, let's assume I have a shopping cart app, the user clicks on the Checkout button.
The next thing I want to do is send the user to a Invoice.aspx page (or similar). When the user hits checkout, I could Button.PostBackURL = "Invoice.aspx"
or I could do
Server.Transfer("Invoice.aspx")
(I also changed the title since the method is called Transfer and not TransferURL)
Server.TransferURL will not result
in a roundtrip of HTTP
request/response. The address bar
will not update, as far as the
browser knows it has received only
one document. Server.Transfer also retains execution context, so the script "keeps going" as opposed to "starts anew".
PostbackURL ensures an
HTTP request, resulting in a
possibly different URL and of course
incurring network latency costs.
Usually when you are attempting to "decide between the two" it means you are better off using PostbackURL.
Feel free to expand your question with specifics and we can look at your precise needs.
Here is a good breakdown between the two:
Server.Transfer vs Response.Redirect
Server.Transfer is done entirely from the server. Postback is initiated from the client for posting form contents and postback url identifies the page to post to.
Maybe you meant to compare with Response.Redirect, which forces the client to submit a new request for a new url.