I'm an experienced web developer in several different web technology stacks. I currently work in .Net and I've become curious about the Partial Postback.
I understand what the Partial Postback's function is and how to work with it programatically, but I don't like using technology that I don't understand, how is a Partial Postback implemented.
I understand HTTP Requests and Asynchronous Requests, the thing that bugs me about the Partial Postback is that it seems to be both.
Maybe I'm just missing something but it appears to me that the Partial Request does both, first firing off an Asynchronous POST Request but the Browser seems to be aware and the activity indicator starts to spin, which normally only occurs during an HTTP Request Page Render.
So can anyone shed some light on how Microsoft implemented, at the HTTP Request level, the Partial Postback?
I know this question has already been answered, but I disagree with the answer...
In my humble opinion, the term 'partial postback' is being misused in the above-mentioned article "How to write your own partial postback in ASP.NET 2.0". In this article, the author shows you how to make an AJAX call to an HttpHandler. This is a very different process than making PartialPostback calls in ASP.NET.
I beleive this 'difference' is eluded to in the (above answers) after-thought comment which states:
"An UpdatePanel not only refreshes the controls which it contains, it also updates the ViewState value with the one obtained from the server, after processing."
While this final comment somewhat elusively-illustrates the definition of a 'Partial Postback' using an ASP.NET UpdatePanel...it doesn't explain what a partial-postback is (which, once again, is a very different process than that of a normal AJAX call).
To elaborate...
MICROSOFT ASP.NET AJAX Using UpdatePanel's:
At a basic level, Microsoft AJAX supports asynchronous requests via a partial-page-postback. Partial postbacks iterate through the same page lifecycle as a synchronous full page postback, but only specific regions or controls on the page are refreshed - thus achieving partial page rendering. MICROSOFT ASP.NET AJAX is dependent on the interceptor pattern to generate and handle a partial-postback. Upon initialization, MICROSOFT ASP.NET AJAX JavaScript libraries add a set of client event handlers to intercept calls that would normally initiate a full page postback. The handler functions intercept postback calls from registered controls, generate a partial postback, process the response content and then update page content asynchronously. Since MICROSOFT ASP.NET AJAX is built on the existing ASP.NET postback architecture it utilizes event-validation and maintains the view state throughout the partial-postback process. Your standard 'normal' AJAX call doesn't do these things!
To put it shortly...
MICROSOFT ASP.NET AJAX uses 'normal' AJAX to 'ajax-ify' it's pages and achieve partial-updates...and in doing so, it trades & manages view-state MULTIPLE times throughout a single call. This is WHY it is called a 'partial-postback'. Subsequently, this is also why they originally described the UpdatePanel as a means to make your pages 'ajaxy' (because it is not the same thing as using AJAX).
NORMAL AJAX Calls:
Asynchronous requests initiated using JavaScript in the browser creates a new connection to a server. Yes...this may include stateful postbacks to a page, but also stateless requests to resources apart from the current page. However, in the case of an asynchronous postback , only the information that needs to be processed by the current page on the server is passed INTO the request (and you can control this). Meaning, the contents of the entire page do not need to be submitted, no view-state needs to be managed & the (native) overhead embedded into the page-lifecycle can be bypassed. Meanwhile, an asynchronous postback only calls server-events associated with processing the CURRENT REQUEST. This is why normal AJAX is so much faster than PARTIAL POSTBACKS!
These Points Illustrate...
Not only WHAT a 'partial postback' is...but WHY there is a difference between a 'partial postback' and an 'ajax' call. Which is why this is a better answer.
From How to write your own partial postback in ASP.NET 2.0:
At the heart of the partial post back construction is the XMLHttpRequest, a DOM API. It can be used inside a web browser scripting language, such as JavaScript, to send an HTTP request directly to a web server without having to reload the entire page and handling the response from the server again within the scripting language. This data, in the form of XML, can then be used to manipulate the page elements on the client side.
When the button on the ASPX page has been clicked, a client side HTTP request is made using the XMLHttpRequest API. This request is handled by an HttpHandler on the web server. The HttpHandler receives the request, processes it, and sends back the response to the XMLHttp object on the ASPX page. The XMLHttp object in turn consumes the response and renders the appropriate UI changes without the browser having to do a full refresh of the page.
An UpdatePanel not only refreshes the controls which it contains, it also updates the ViewState value with the one obtained from the server, after processing.
Take a look at:
http://www.codeproject.com/KB/aspnet/PartialPostback.aspx
Related
i have an argument at work about the best way to implement ajax handling for forms. we build all our forms under asp.net platform (sharepoint to be exact) but since we talk about public sites we though to cut the time-costing postbacks and make all postback in ajax request.
in order to best implement the server side i took a bit deeper look into handlers and modules and i then thought that i can cut all that by implementing a module that in his beginRequest identifies if its an ajax request (say by a special element in the querystring), and if so call CompleteRequest() and then in this module's endRequest if it was our ajax (say i flagged it in beginRequest) handle it.
so i would like to hear your thoughts about the pro's and con's about it, and also how "dangerously" it can impact the entire website ect.
the other option is, o.c., a generic handler (ajaxHandler.ashx).
i am again stating we are talking about IIS7+ where they integrated the pipelines.
p.s.
another thought is to build a WCF that will have to "open" (create instances) of anything that i would already have in my handler/module (in sharepoint for example the SPContext)
regards
Bresleveloper
I have the following use case:
A user can filter on my asp.net web project for some data and request the result as PDF. The PDF is generated per request new and returned to the user. I got already everything to run.
But: the processing can take up to two minutes and the user should be able to continue to use the page.
I tried to use a second tab, but both tabs are blocked. Even when I use the PageAsyncTask class and the async attribute. When I use a thread to perform the request, I am truly parallel, but I have no clue, how to interact with the user from inside the thread when the work is done.
How can I send an async request to the server and just get the result on the page, in whatever form, when its finished?
Dave Encosia does a great job explaining how you can do this:
Using jQuery to directly call ASP.NET AJAX page
methods
Using jQuery to Consume ASP.NET JSON Web
Services
3 mistakes to avoid when using jQuery with ASP.NET
AJAX
a colleague of my said that a MVC 3 app handles all incoming requests one at a time.
So when i make two AJAX calls to my application from a webpage, asp.net MVC / IIS handles the first request first, then returns the result and then processes the second request.
He has this line of documentation from MSDN of evidence (http://msdn.microsoft.com/en-us/library/ee728598(v=vs.98).aspx)
You can use asynchronous action methods for long-running, non-CPU
bound requests. This avoids blocking the Web server from performing
work while the request is being processed
Where it says that 'asynchronous action methods' don't block, so 'normal' controller actions do.
He also said that he saw that in effect on his page ( in the browser debug tools, lokking at the request sent), that first ajax request one was processed, and then, even that it was fired at the same time as the first by the browser, the second.
I find it hard to believe that IIS can only serve one request at a time per application?
If you are on the same session, then AJAX queries will be serialized (one at a time).
You can change your controller to be sessionless. See What are some scenario's of having a Session-less Controller in ASP.NET MVC3?.
The knowledge I have about UpdatePanel is
They use Ajax requests to work asynchronously.
They perform a partial postback.
Now recently I was working on Ajax requests too using $.ajax() method of jQuery when I found some difference about Ajax requests made by me and Ajax requests made by UpdatePanel which are
UpdatePanel's Ajax request perform full page life cycle but my Ajax request calls only that particular method which I have supplied to be called.
Methods called by UpdatePanel doesn't need to be tagged as WebMethod but methods called by my Ajax request has to be WebMethod.
I searched web to get details about these differences but doesn't found any resource, Can someone tell me whats the difference between Ajax calls made by me and by UpdatePanel or more specifically hows those differences made and what special tricks are played by UpdatePanel to achieve that functionality ?
I liked this question mate +1
Basically the evil UpdatePanel is the root of all evil. Sadly it is =(. The update panel behind the scenes raises async postbacks to the server, but to fully understand what happens, you need to understand the UpdatePanel goal
The UpdatePanel was designed to work with the ASP.Net web forms, these controls have to go through the whoooole ASP.Net page life-cycle in order to work correctly, therefore, they need the whoooole page ViewState. So every time you perform a post back using an UpdatePanel the whole page viewstate will be sent to the server back and forth even when you only want to partial render a small part of your page.... sucks. Why did Microsoft created this monster? I think it was because back 5-6 years ago (or more) AJAX was not so popular as it is today. Another reason is that Microsoft wanted to provide a framework to write AJAX calls in a simple way, but without losing the power of the web controls.
So with this in mind, the difference between an UpdatePanel and an AJAX call, is simply:
The AJAX call sends only the data needed by the server method and it returns just the required data. The performance of using pure AJAX calls is impressive.
but methods called by my Ajax request has to be WebMethod.
That's partially true, I mean there are different ways to expose methods from the server:
Using traditional Web Services - Script services (ASMX)
Using PageMethods (static methods on your ASPX pages)
Exposing WCF services
Exposing WCF REST services
Using WEB API
Using MVC controller's actions
Using custom HttpHandlers returning a specific content type like JSON
etc
At the end the result is the same, no matter what approach you use to expose server methods when consuming them with pure AJAX calls you will have to face the following if you are using web forms:
If you want to use pure AJAX calls, then you should consider moving to MVC because in web forms you will lose the power of the web controls, in other words your development would be more difficult
They perform a partial postback.
No, update panels perform a full postback, they just perform a partial update on the page.
UpdatePanel's Ajax request perform full page life cycle but my Ajax request calls only that particular method which I have supplied to be called.
Precisely, the Update panel performs a full postback. Highly inefficient.
Is there any limitations on AJAX Calls with ScriptManager to Web Services?
I have an application and I need an AJAX enabled form in it. After every Insert or Delete, I have to get a list from database and show it on page. So I call two server methods from my JS.
Isn't too many AJAX calls gonna cause any errors(eg. timeouts, transfer errors etc.)?
Too many of any kind of request will give you the same things to worry about. An AJAX request is just like any other HTTP request, a ScriptManager control won't be imposing any constraints.
The only limitation is your hardware and your IIS settings (application pool connections, etc.).
Of course, you should always be smart about how you program your methods, utilize caching where appropriate, etc. to ensure that they will hold up under heavy load.