Treating an ASCX control as independent

One huge disadvantage of the UpdatePanel control, IMHO, is that all of the Page life cycle reloads again.

I was wondering, when I just want to load a single control that has nothing to do with the rest of the stuff on the page, is this roundtrip really necessary?

I know that there's the client approach which says I can communicate with the server with minimal data and create all controls at the client-side, but that won't let me use server-controls and their benefits.

I thought of something that renders an ASCX control and serves its HTML, but it not covers everything, such as event firing.

Is my idea doable? Anyone bumped into this before?

Thanks!

If you want the benefits of the server controls you must also allow their life cycle to run. It's both the advantage and the disadvantage of the UpdatePanel.

Agreed... This is discussed here:http://encosia.com/index.php/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous

One option is to use ASP.NET PageMethods (also described in that link) which simplifies WebMethod calls and only returns results and not much overhead. You can also use multiple UpdatePanels so that you aren't refreshing so much.

Hope this helps,

-Damien

Trying to implement a thread queue for page with 6 update panels

I am attempting to write a FIFO thread queue for the dashboard portion of a portal application. There are 6 update panels that refresh independent of each other about every 60 seconds, so there are a lot of postback collisions and I need something to save postbacks and re-issue them when the callback from the prior async call is returned.

It looks like there has been quite a bit of effort put into this, but none of the code I could locate would work in my situation because of various "can't find id", "null reference", and "object does not have this function" -related js errors.

Here is what I have so far:
Sys.Application.add_load(ApplicationLoadHandler)

function ApplicationLoadHandler(sender, args)
{
var prm = Sys.WebForms.PageRequestManager.getInstance();
if (!prm.get_isInAsyncPostBack())
{
prm.add_initializeRequest(InitializeRequest);
prm.add_endRequest(CompleteRequest);
}
}
// initialize a queue
var myQueue = new Array();

function CompleteRequest(sender, args)
{
if(myQueue.length > 0)
{// fire correspond event again of the item cached
var control = $get(myQueue[0]);
setTimeout('__doPostBack(\'' + control.id + '\',\'\')', 0);
Array.removeAt(myQueue, 0);
}
}
function InitializeRequest(sender, args)
{
var prm = Sys.WebForms.PageRequestManager.getInstance();

if (prm.get_isInAsyncPostBack())
{
// if it's working on another request, cache the current item that cause the request
args.set_cancel(true);
Array.add(myQueue, args.get_postBackElement().id);
}
}

if(typeof(Sys) !== "undefined") Sys.Application.notifyScriptLoaded();

Even if this did work, it wouldn't do what I want it to do because '__doPostBack(\'' + control.id + '\',\'\' would strip out all of the eventargs that were sent along with my postback (for instance, if the user initiated the postback via mouse click) and turn "doPostBack('gridviewSomething', 'Select$1')" into "doPostBack('gridviewSomething')", which is clearly no good.

This code will properly interrupt postbacks and save them to queue, but upon callback and re-initiation I get problems. Anyone have any suggestions? I feel like this is so close and I am loosing my hair over it, so help is much appreciated.

Merry (early) Christmas.

http://disturbedbuddha.wordpress.com/2007/12/12/handling-multiple-asynchronous-postbacks/