Web Application, Postback and Dynamic User Controls

[balabaster]

I've got a user control that builds a table of dynamic data based on a :LINQ class holding the data. The data is loaded using the LoadData(DataInstance) method. The table it builds contains a number of dynamic controls that themselves have postback/autopostback so the display of the control needs to be built at latest in the Page.Load event or the event handlers for the controls don't get wired up.

Now if I have a page that uses this user control by passing the data in the page load, the control loads the data just fine. However, if I want to load the control with data as the result of a user made selection - say, a dropdownlist that has autopostback, it doesn't.

I understand why this is; on the postback, the page load event fires, which loads the control that doesn't yet contain any data because at this stage of the lifecycle the selection event handler hasn't yet been filed. Then the event handler fires which passes the data to the user control.

Now, one of two things happens depending on how I wire the control up. Either I have it reload the display, at which point, the event handlers are missing because they're required to be wired up in the page load, but I do have the data and the buttons displayed; OR, I don't reload control displaying the data at which point none of my controls have yet been loaded in the user control and consequently only the basic user control template is displayed.

So the question boils down to - what do I do about this? I found a couple of hack workarounds - i.e. reference the Page.Request.Params("__EVENTTARGET"). The only problem with this is that my user control loads a substantial amount of controls and having to parse the Request.Form object to figure out what was changed, and whether it's value field is called "VALUE", "TEXT", "SELECTEDVALUE" or some other named field... is a little laborious.

Any suggestions as to how to deal with this limitation of the page lifecycle? I'm wondering if there's a way that I can force the event handlers to be wired up in the Page PreRender event - even if I do this manually? If I can do this, then I can move the place the user control is built and still have the event handlers work - which is the way this *should* work in my opinion - but that's just me. If anyone's got any ideas, I'd welcome them...

[kenobewan]

Is this a problem that can be resolved by using the (not/!) page.ispostback property? An alternative is partial page refreshes using a panel.

Or do I need to fire my speed reading teacher ;)?

[balabaster]

Haha, um, I don't think you need to fire your speed reading teacher.

However, the issue cannot be resolved by using is or is not postback. The reason for this is that the request for the ASCX to load the data doesn't occur until the postback - because we don't know what data to load until the end user tells us what they're looking for. However, all the controls' event handlers are (at the very latest) wired up in the Page.Load event, at which point we don't know what data needs loading - so we're in a Catch 22 situation.

By the time the ASCX knows which data to load, it's too late to wire up the dynamic event handlers. So we either need a way to know what data to load earlier, or find an ability to wire up the event handlers later in the page lifecycle.

To find out which data to load earlier, I can use some hack mechanism like Page.Request.Params and finding the selection control's selected index, or more preferably I'd like to add the ability for the Postback or PreRender phases to hook up the event handlers the way that PageLoad does.

Both have their advantages and drawbacks. On the plus side, Page.Request.Params at first glance is a simple mechanism that can be used for this. However, depending on the control that caused the postback, the value property may be any of TEXT, VALUE, SELECTEDVALUE, CHECKED etc etc. With a button it's nice and easy, you can cast the button as IPostBackHandler and fire the event. However, with other controls, you can't cast them as IPostBackHandler, and apparently there's no simple way of figuring out their event handler and firing them. So while this solution may be a possibility it is far from elegant as I have to Select Case/Switch the control to see what it's class type is and then call a hardwired event handler for it - which is about the suckiest solution I can think of.

Being able to wire a dynamic event handler in the PreRender - or even the PostBack phases would be far more elegant as I can wire whatever event handler I like and it will still be handled on postback. This means that I can have my ASCX build the display right after it's loaded the data and the event handlers would still be able to be handled. However, so far, I've not been able to find a method to do this. I've not been able to find a single useful explanation of how .NET actually wires up event handlers in ASP.NET in the underlying code.

I am currently using an update panel in the ASCX itself to modify the data it loads which itself works like a charm, but I can only get it to load the data in my test harness pages where I hardcode the key of the dataset I wish to load - which is used in the page load. Even if I put a button outside my update panel and put the Control.LoadData(DataInstance) call in the button postback it stops working once more, because even in the UpdatePanel, it still doesn't load the data until the PostBack (even if it's done behind the scenes asynchronously, it does a full page lifecycle) phase. It then upon getting the response just updates the content of that panel with the matching panel from the response.

So there you have it - I've explored all the options I can think of and appear to have come up against dead ends (so far) in all cases.

[kenobewan]

Here is an article that answers most of your questions:
Dynamic Web Controls, Postbacks, and View State

This MSDN section should also be of use:
Server Event Handling in ASP.NET Web Pages