ICallbackEventHandler - Ajax chaining

[Ian]

Is it possible, when using ICallbackEventHandler, to chain Ajax
requests together, with the callback of the 1st method providing the
client-side function name of the 2nd?

Actually I know the answer to that one is "yes"... the real question
is: is it possible to do this without causing an infinite loop?

On the client, I've got something akin to the following:

function FirstCall() {
var message = 'FirstServerMethodtoRun';
<%=sCallBackFunctionInvocation%>
}

function SecondCallAndFirstMethodsCallbackFunction() {
var message = '2ndServerMethodToRun';
<%=sCallBackFunctionInvocation%>
}

function SecondMethodsCallbackFunction() {
alert("Yaay. We should be done now");
}

function CallbackEvaluator(s) {
eval(s);
}

On the server, sCallBackFunctionInvocation looks something akin to:
Page.ClientScript.GetCallbackEventReference(this,"message",
"CallbackEvaluator", "context", "postBackError", true);

So:

An onClick triggers FirstCall, which runs server-side no problem. That
server-side method returns, as its Callback, a string value that
contains the name of the 2nd method. The 2nd method also runs just
fine, and its Callback returns the name of its callback (the alert
box), which also runs fine.

My problem is that then it starts an infinite loop between the 2nd
callback, and the final alert callback. So, instead of:
Method1 -> Method2 -> Alert

It goes:
Method1 -> Method2 -> Alert -> Method2 -> Alert -> Method2 ->
Alert -> Method2 -> forever.

What have I missed (except maybe the obvious lesson to not try to chain
more than 0 ajax requests together). It doesn't seem that this should
be impossible nor even that problematic, but I can't seem to see how I
get the page to stop infinitely calling methods it's already received a
callback from.

Have tried a variety of JavaScript tricks in here (return false, etc),
but still infinite loops.

 

[Andy]

I'm a bit confused as to what the goal of the code is...

Ajax is an XML parser so are you trying to send XML back and forth?

To me, it looks like you are actually posting whole webpages (rather
than transmitting just XML between the server and cllient). If so, you
should consider putting a:

if Page.IsPostBack then

endif

statement into your Page_Load event handler on the server side
code-behind. Page.IsPostBack will return "true" if the page you have
just received is the result of the code-behind for the page having sent
the page back to the client (which would be start of the second
iteration of the loop in your example).

You can then use this condition to isolate the call that causes the
third iteration of the loop to prevent from firing on a postback.

 

[Laurent Bugnion]

Hi,

I'm a bit confused as to what the goal of the code is...

Ajax is an XML parser so are you trying to send XML back and forth?

Ajax is not a XML parser, it's a concept. It englobes applications using
JavaScript to send XML encoded requests asynchronously (AJAX =
Asynchronous JavaScript and XML). Loosely, the term is often used to
describe any kind of XML-based service running on HTTP, synchronous or
asynchronous, JavaScript based or not.

To me, it looks like you are actually posting whole webpages (rather
than transmitting just XML between the server and cllient).

Even if he does, it could still be Ajax, since HTML is XML (well...
almost

HTH,
Laurent

 

[Ian]

I'll try to clarify. We're developing an application which, for all
intents and purposes, exists in a single page. It contains a large
number of controls, draggable divs, etc. We would, at all costs, like
to avoid implementing full postbacks. Re-creating the exact state of
application content on postbacks would be a huge headache, so as much
as possible, we are trying to update page content in asynchronous
chunks.

With one of the controls we're using, we need the pseudo page-lifecycle
model that ICallbackEventHandler implements. We'd like the logic on the
server to dictate which subsequent client-side methods should be
triggered, hence attempting to return client-side method names as the
GetCallbackResult() content.

Where it's glitching up seems doesn't seem to be the Page lifecycle but
on the client, and I'm trying to understand why. For example:

If instead of chaining the 2ndMethod call inside of 1stMethod's
callback, but instead I write it out to a textfield in the page, then
have the user click on another button to javascript:eval that method,
it works fine. It's only when I try, as part of the Callback, to issue
another async request that I get caught in an infinite loop.

Probably none of this makes much sense and I will probably just change
the architecture as to avoid spending several days going through
low-level JavaScript plumbing, but was curious if anyone else had
bumped into this.

 

[Ian]

In case anyone finds this thread later with a similar issue, I'll reply
to my own thread since no one else had useful ideas.

I found the problem, which is best explained in the following post:

http://forums.asp.net/thread/1392512.aspx

The poster writes:
"The problem is due to the point at which the WebForm_ExecuteCallback
function gets invoked. This function "WebForm_ExecuteCallback" is
responsible to invoke the OnComplete function. But the
"__pendingCallbacks" "global" array is updated only after executing the
callback function. Note that "__pendingCallbacks" global array is also
used inside "WebForm_DoCallback" function to add new requests in
pending list. "