I finally got back to taking another look at the UpdatePanel code I started messing with the other day for my ASP.NET Connections workshop. It's not going well <g>… 

I posted the sample here if you want to check it out:

http://www.west-wind.com/presentations/scriptcallbacks/sample/Atlas/CustomerListAtlas.aspx

In the last message I posted I was trying to get the control to work without Viewstate in the list getting pushed back and forth on every hit and I managed to get that to work for single a single UpdatePanel to update a bunch of textbox controls. Easy as pie – except the little detail that you had to know exactly when to databind the list. But look Ma, no JavaScript.

Now that that's working I need to add more functionality – implement Save operation and be able to update the list when a Save is performed. Two things need to happen: I need to have the UpdatePanel for the textboxes fire both on selection from the list and a save operation. The way to do that with an UpdatePanel is attach event triggers which in this case look like this:

<atlas:UpdatePanel ID="CustomerUpdatePanel" runat="server" Mode="Conditional">

<Triggers>

     <atlas:ControlEventTrigger ControlID="btnSave" EventName="Click" />

     <atlas:ControlEventTrigger ControlID="lstCustomers" EventName="SelectedIndexChanged" />

</Triggers> 

<ContentTemplate>

 … Updateabale content – textboxes and labels in this case

</ContentTemplate>

UpdatePanel works great for the one off case where you need the panel to update one area and you have a single event firing. So in my scenario I have a listbox on the left and a detail area with a bunch of textboxes that are getting updated from the callbacks.

But with the second trigger – the Save operation I run into a big problem right away: When I click on Save both the List OnselectedIndexChanged event is firing as well as the button click. Huh?

In the last post I removed the ViewState requirement by rebinding the list on every hit to the page including Callbacks. Apparently ATLAS is interpreting the databinding that occurs in OnInit() (note prior to any control value binding from ViewState or POST data) as a change event and is accordingly firing the SelectedIndexChanged event.

So – if I understand this correctly this means that you can't rebind if you want to bind to a change event. Now mind you this works on a standalone ASPX page – Change events aren't supposed to be generated if you change the value inside of your server code. They are supposed to get generated from Postback value changes.

Anyway, the only way to make it work at all was to go back to using list ViewState which sucks big time. Now it works, but the list data is sent back and forth for updates of EVERY callback. It goes back to the server and then also gets sent back to the server.

It gets worse though. I wrapped the Customer List example into another UpdatePanel. Both panels are marked with Mode=Conditional, which is supposed to keep the panel from updating. However, ATLAS is updating the panel regardless of a trigger not firing or explicitly having called UpdatePanel. So it's updating and shipping the entire List as HTML in addition to all the lovely ViewState.

My, don't we have a nice and lightweight callback now? But hey I didn't have to write 20 lines of Jscript code, so this must be better <g>…. I hate JavaScript as much as the next guy, but this is pretty out of control.

I've updloaded the demo and you can check it out in all its gory ugliness. Make sure you hook up Fiddler or the like to see what goes over the wire.

This is a pretty simple scenario but it demonstrates a couple of important points. First that although the concept sounds really simple – drop a panel around a few controls and click away – the reality is that it's not all that simple. There are a number of things that will be subtly different on these update callbacks that affect the page cycle.

It's hard to tell whether these are issues in the control, or whether this is a design issue. Or whether I'm just out to lunch and missing the obvious…

What we have here is a case of leaky abstraction built ontop of another already abstraction (ASP.NET). So now we have client side code trying to emulate server behavior, and we have server side code trying to emulate a Win Form interface. Abstraction piled on abstraction. It works in simple cases, but as soon as you go beyond the simple case or start mixing a few of these types of 'ATLAS' controls together you're all of a sudden in a morass of Page Pipeline event sequence hell. Once you've arrived here – you're much worse off IMHO than writing say JavaScript on your own.

In all fairness - it's early in the cycle and some of these controls are relatively new. And I thin that using UpdatePanel for some of the things I'm doing is not really the best choice. Updating a list with an UpdatePanel is likely not the right way to go. But if you look at it from a 'out of box experience' that's the first thing somebody would probably want to try out based on a vague description of the ATLAS controls.

But if you compare this example with say the Anthem or wwHoverPanel samples I created - it's really not that big of a stretch to say that even though there's less code in the ATLAS sample, that it was conceptually much easier to understand the other samples. Easier to explain too -  you can see the moving parts and if necessary change them. With ATLAS you have a very big black box that shuttles a lot of data between client and server.

You can judge for yourself.