I am a bit curious how ASP.Net internally identifies that the request is a postback.
I have read in a Microsoft book that you can technically do a postback using both POST and GET methods
This means that commands do not have anything to do with postback.
I have tried to use Fiddler to see what the request headers are sending. I am thinking that it could be something to do with the viewstate but I am not sure.
You're nearly right.
The correct event is fired based on the _EVENTTARGET and _EVENTARGUMENT variables which are sent as part of the request. I believe the IsPostBack is set based on the values of these. These determine which event to fire and with what arguments.
The actual submit is fired by the __doPostBack() function in javascript.
More detail here: http://dotnetslackers.com/Community/blogs/haissam/archive/2007/05/18/Which-Control-Caused-PostBack_2100_.aspx
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
Been through a few threads and wasn't able to find this situation exactly. My page is ASP.NET 4.5, C#. I use "Server Side" validation for (IMHO) security reasons and have several validation groups on a dynamic form.
I think we are all familiar with the advantages of disabling a button during Postback to prevent double clicking. I've read through quite a few threads with examples using OnClientClick in various ways.
What I'd like my page to do is something like this:
1 - User clicks Submit (or whatever button)
2 - Server-side custom validation fires on appropriate validation group
3 - if the validation passes, disable the client button(s) and proceed with Postback
4 - if the validation doesn't pass, show the error as usual. Client buttons should still be enabled.
Number 3 seems to be the kicker. Is this even possible with server-side validation? It seems out of order to validate server-side, come back to execute javascript, then back to postback. If it is possible, then I'm muddy on some of the mechanics. Specifically, how to tell the client that the specific validation group passed okay on the server side. Less specifically, the entire thing, lol.
Thanks!
Since you're using ASP.NET, I'm assuming you're also using jQuery (which is the default).
$('#MyForm').submit(function (event){
event.preventDefault();
var form = $(this);
if (!form.data('submit-lock')){// check if we're waiting on the server's response
form.data('submit-lock', true);// set the lock since we're about to post to the server
$.ajax(/*your url and data and whatnot here*/)
.always(function(){
form.data('submit-lock', false);// the server responded, unlock
});
}
});
$.ajax() returns a jQuery Deferred promise object.
promise.always(function) registers a function to call when the ajax is resolved (success) or rejected (fail).
More reading on the deferred pattern:
http://joseoncode.com/2011/09/26/a-walkthrough-jquery-deferred-and-promise/
I'm having the same problem I had yesterday... The solution Aristos provided helped solve the problem, but I have other places sending updatepanel postbacks causing the same problem.
When an update panel is updated and another request for an update is called before it has a chance to render the first updates, the entire page refreshes instead of just the update panel.
I used fiddler to see what was going on and here's what happens... If I wait for the request to return before doing another request I get this:
21443|updatePanel|dnn_ctr1107_CRM_SalesTool_LeadsUpdatePanel|
But if I don't wait, I get this:
66|pageRedirect||http://mysite.com/salesdashboard.aspx|
The code from the previous question is still the same except I added UpdateMode="Conditional" to the update panel.
Any ideas? Or is the only solution to this making sure that 2+ updates for any number of update panels (as long as they're on the same page) never happen?
Thanks,
Matt
Maybe microsoft automatic ajax can not handle 2 request at the same time because he needs to know what is the post back every time, so probably if you click when he wait for a return, then he knows that the post back, has change, so he by pass ajax to be soure for correct return.
I can think 2 ways. One way is to make it by your self using jQuery and ajax and avoid UpdatePanel.
Second way, is to block the clicks when you wait for the return, or make a mechanism to place the request, the one after the other.
This code can help you know when you block the input and when you release it, or do what ever you think.
$(document).ready(function() {
var prm = Sys.WebForms.PageRequestManager.getInstance();
prm.add_initializeRequest(InitializeRequest);
prm.add_endRequest(EndRequest);
});
function InitializeRequest(sender, args) {
LastIdCaller = args.get_postBackElement().id;
}
function EndRequest(sender, args) {
}
I could be wrong, but if I'm right then you can't do multiple ajax request if you are using asp.net WebForms. In asp.net WebForms there is only one Form element on a page. Multiple ajax requests on the same page require multiple form elements for each. Html is designed to post back inside a form element and the mechanism that handles said postback is the form, it's the container. Only one can post back at a time. So because Asp.Net WebForms only has one form element per page, you can only do 1 ajax postback per page.
Optionally, you can create generic ASHX Http Handlers to do your form logic and use JQuery Ajax to post back to the Generic Http Handlers. In which case you can do as many of those at a time as you want.
Generally I use ASHX handler's any time I need to serve images that change, like on the fly imaging. I also use them for large data outputs. E.g. the ASHX handler returns a big dump of JSON. I do an Ajax Postback to the ASHX handler to get a set of data in JSON and append it to a table etc and I call the ASHX handler repeatedly on a timer to get new Data as it comes in (say a 5 min timer) etc.
If you gave some more context on what your trying to do I might be able to provide you with alternative solutions.
Edit: I looked at your other post you linked and I think an ASHX handler would serve you well. You can design the ASHX handler to return your Search Data in JSON. You can use Request varaibles in the ASHX handler and you can send post data to the ASHX Handler with JQuery.Ajax.
You should be able to fire off multiple requests each with it's own Success Function. Then you would need to write the javascript in such a way that as it's processing the JSON data from the ashx handler it can merge with other requests as they finish.
I implemented a save-draft trick using an update panel whereby I handle the updatepanel's asynch postback on the server side and then to avoid resending the same html data I throw an exception with the current datetime as message and then capture it on the client side where i do some transformation and html injection to let the user know that a draft of his current work has been saved (TERRIBLE!).
The original idea was to handle the asynch postback and then override the rendering method of the update panel to send xml or javascript data that could be captured and processed on the client side stopping the update panels refresh from occuring.
Has anyone tried this kind of functionality using update panels?
I don't think that an UpdatePanel is really what you want here. If you're wanting to get the response back and have the best control over the response you should look at standard AJAX requests.
An UpdatePanel isn't something that you can really control the response of all that well, you can tie into the endRequest event handler on the PageRequestManager, there you can check the respose. Here's the details on the eventArgs you get back - http://msdn.microsoft.com/en-au/library/bb384175.aspx
But throwing an Exception isn't a good idea because nothing exceptional has happened, which is what an exception is ;)
I have a problem with maintaining state in an ASP.NET AJAX page. Short version: I need some way to update the page ViewState after an async callback has been made, to reflect any state changes the server made during the async call.
This seems to be a common problem, but I will describe my scenario to help explain:
I have a grid-like control which has some JavaScript enhancements - namely, the ability to drag and drop columns and rows. When a column or row is dropped into a new position, an AJAX method is invoked to notify the control server-side and fire a corresponding server-side event ("OnColumnMoved" or "OnRowMoved").
ASP.NET AJAX calls, by default, send the entire page as the request. That way the page goes through a complete lifecycle, viewstate is persisted and the state of the control is restored before the RaiseCallbackEvent method is invoked.
However, since the AJAX call does not update the page, the ViewState reflects the original state of the control, even after the column or row has been moved. So the second time a client-side action occurs, the AJAX request goes to the server and the page & control are built back up again to reflect the first state of the control, not the state after the first column or row was moved.
This problem extends to many implications. For example if we have a client-side/AJAX action to add a new item to the grid, and then a row is dragged, the grid is built server-side with one less item than on the client-side.
And finally & most seriously for my specific example, the actual data source object we are acting upon is stored in the page ViewState. That was a design decision to allow keeping a stateful copy of the manipulated data which can either be committed to DB after many manipulations or discarded if the user backs out. That is very difficult to change.
So, again, I need a way for the page ViewState to be updated on callback after the AJAX method is fired.
If you're already shuffling the ViewState around anyway, you might as well use an UpdatePanel. Its partial postbacks will update the page's ViewState automatically.
Check out this blog post: Tweaking the ICallbackEventHandler and Viewstate. The author seems to be addressing the very situation that you are experiencing:
So when using ICallbackEventHandler you have two obstacles to overcome to have updated state management for callbacks. First is the problem of the read-only viewstate. The other is actually registering the changes the user has made to the page before triggering the callback.
See the blog post for his suggestions on how to solve this. Also check out this forum post which discusses the same problem as well.
I actually found both of those links you provided, but as noted they are simply describing the problem, not solving it. The author of the blog post suggests a workaround by using a different ViewState provider, but unfortunately that isn't a possibility in this case...I really need to leave the particulars of the ViewState alone and just hook on to what is being done out-of-the-box.
I found a fairly elegant solution with Telerik's RadAjaxManager. It works quite nicely. Essentially you register each control which might invoke a postback, and then register each control which should be re-drawn after that postback is performed asynchronously. The RadAjaxManager will update the DOM after the async postback and rewrite the ViewState and all affected controls. After taking a peek in Reflector, it looks a little kludgy under the hood, but it suits my purposes.
I don't understand why you would use a custom control for that, when the built-in ASP.NET AJAX UpdatePanel does the same thing.
It just adds more complexity, gives you less support, and makes it more difficult for others to work on your app.