the update panel works pretty simple. when a async postback is done,
javascript calls __dopostback, which builds a string of all form elements and
their values (in the same format as a form post) and posts the values to the
page via xmlhttprequest.
the server process the page as a normal postback, but only collects the html
output (calls render) on the update panel(s) as the request was marked as an
async postback. it then returns the html (and script as piped delimited data)
to the client. the client receives the response, and sets the innerHtml of
the update panel's div to the returned html. it also will process any return
javascript the scriptmanager sent back. javascript support was adedd mostly
for validator support.
some other work that needs to be done, is before replacing the html, the
updatepanel has a list of all client components that must be "disposed".
if the amout of replacement html is small, then its faster then a true
postback, but as the size grows, its becomes more expensive.
-- bruce (sqlwork.com)
"Mike Gleason jr Couturier" wrote:
Hi guys,
I know that the page is reconstructed every time whenever an asynch postback
is occuring... I've put a breakpoint in the page render method and the
function still gets called when the postback is an asynch one.
Is the framework optimizing the rendering process on asynch postback?
How does the __doPostBack() is working whenever an asynch call is made? Is
the page gets constructed as if it was not "in AJAX mode" and the parts
updated on the client screen is extracted from the server response (in
JavaScript)?
It's the parts I'm missing
Thanks guys