What's up with UpdatePanels and how come nothing works? Or: A brief explanation of how UpdatePanel works by the guy who wrote the feature. (Long!)

This is a repost from a post I made to the ASP.NET Forums:


With the recent Microsoft ASP.NET AJAX Extensions release there has been a lot of feedback, both positive and negative, about the changes made to UpdatePanels. The feedback has ranged from “wow, finally validators work” all the way to “what the $%*@, my custom control doesn’t work!”


The biggest change we made was related to script registration during async posts. We used to do some extremely hacky parsing work to detect the scripts rendered in a page and try to execute them on the client.




Atlas CTPs (pre-beta):

In the CTPs we had a special response writer that would parse the rendered contents of the page. It would look for specific items such as <script> tags, <input> tags, and a few other things. It worked really well for trivial scenarios such as a GridView with a textbox and a validator on the page. Unfortunately for us it turned out that most pages are significantly more complex.


A classic example that didn’t work was a page that had an UpdatePanel with a wizard. Each step of the wizard contained a validator and a textbox. As you go through the wizard steps validators conceptually get removed and added to the page but nowhere was there any JavaScript code to remove the validator from the page. We would just keep adding more and more validators. Busted!




Microsoft ASP.NET AJAX Extensions 1.0 beta:

To overcome the problem of blindly reexecuting scripts that we parsed from the page we came up with an explicit registration model for scripts. This way the UpdatePanel can known exactly which scripts to execute, and when. The ScriptManager now has a set of static script registration methods. They are static so that they work on pages that don’t use partial rendering, including those that don’t even have a ScriptManager. You do, however, have to link to the Microsoft.Web.Extensions.dll to be able to call these.


If you used to call:

            Page.ClientScript.RegisterClientScriptBlock(typeof(Foo), "key", "alert('hello'); ", true);

You would now call:

      ScriptManager.RegisterClientScriptBlock(this, typeof(Foo), "key", "alert('hello');", true);


If you look closely, there’s a new parameter for the method of type Control. This parameter is the precise reason why we needed the new set of registration methods. We use that parameter to detect whether the control registering the script is inside an UpdatePanel, and if so, whether that UpdatePanel is being refreshed during a given async post.


We also require that controls implement dispose logic so that when an UpdatePanel is cleared out during an update the scripts inside it can tear down anything they need. This is done through a number of techniques, which I won’t go in too much depth here. The technique the validators use is to have a “dispose” expando on their rendered elements and the UpdatePanel client code will execute all the “dispose” expandos inside a panel that is getting cleared.


Implications of having new registration APIs:

One of the biggest implications of this is that existing controls that register scripts don’t work inside UpdatePanels. We are aware that this is a problem but we saw that it was necessary in order to make UpdatePanels work at all.


Controls that shipped in ASP.NET 2.0:

We have updated versions of the ASP.NET 2.0 validators that are tag-mapped to the old versions (this means that if you have an <asp:RequiredFieldValidator> tag it will use the updated one and not the old one. These updated validators use the new registration APIs.


Other controls, such as WebParts, TreeView, and Menu were not updated to use the new registration APIs primarily due to time constraints. We felt that it was far less common to have these controls inside UpdatePanels compared to the validators. The TreeView control has built-in AJAX functionality anyway. In a future version of Atlas or ASP.NET we will have updated versions of these controls, however.


3rd party controls:

We have been working closely with custom control vendors to have them learn about the new APIs and many of them will be releasing updated versions of their controls that are compatible with UpdatePanel.





We’ve still got a few things to work out for custom control vendors. And there are also some issues remaining for page developers. We love hearing this feedback from you since it makes a huge difference in how we build this awesome framework.



I hope this helps explain some of our decisions in one place instead of scattering it in varied responses to several posts.



  • &quot;Other controls, such as WebParts, TreeView, and Menu were not updated to use the new registration APIs primarily due to time constraints. We felt that it was far less common to have these controls inside UpdatePanels compared to the validators. The TreeView control has built-in AJAX functionality anyway. In a future version of Atlas or ASP.NET we will have updated versions of these controls, however.&quot;
    Actually, I have used the update panels for menus because having a postback is the most unnatural thing (most of the postbacks on the controls feel unnatural). &nbsp;Not quite sure where you got your &#39;less common&#39;, I must have missed that poll ? &nbsp;
    &quot;due to time constraints&quot;
    Curious - why the rush? &nbsp;Why not get it right the first time so we don&#39;t have to constantly go back and fix things over and over again - it&#39;s beta right?
    I think the team needs to get out more often, the most significant uses of an update panel is the ability to put any of the .net server side controls inside the panel with the expectation that it will work. &nbsp;Validation is equally important, although the built in validation controls seem to fall short of any complex senarios - ie. radiobuttonlists, multi-combination validation senarios, etc..
    That being said, I&#39;m glad to see the ability to attach different progress indications with a time setting, this has been my request since day one.

  • Now i know who to blaim! ;-)

    Just kidding. The updatepanel rules

  • Hi Eilon,
    I have just installed ASP.NET AJAX BETA 2. I have two questions. Your answers are much appreciated.
    (1) Web.config entries.
    -&gt; When I look at the web.config provided with C:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025\web.config, it has many many keys. Does all these key required in my application&#39;s web.config. Right now I have only added &nbsp;&lt;add assembly=&quot;Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35&quot;/&gt; and &nbsp;&lt;add verb=&quot;GET&quot; path=&quot;ScriptResource.axd&quot; type=&quot;Microsoft.Web.Handlers.ScriptResourceHandler&quot; validate=&quot;false&quot;/&gt; keys. Do I need to copy other keys from other sections of supplied web.config?
    (2)Now I am using Rating controls and Popup control inside Update panel. The Rating controls works sometime but not all the time. What could be reason? Not adding all of web.config entries?
    Please help.

  • Hi Vishant,
    (1) Most of the entries are optional. It all depends on which features of ASP.NET AJAX you use, such as Web Services, advanced serialization, IIS7 support, modified validators, etc.

    (2) I'm afraid I don't know. A great place to ask is on the ASP.NET Forums for the AJAX Control Toolkit (http://forums.asp.net/1022/ShowForum.aspx).


  • Is there a list somewhere which mentions which controls are currently compatible with Update panel? Otherwise after partial development is over, we realise this or that control is not compatible.

    It would be really helpful if a list can be published somewhere.


  • I Believe I have had enough of ASP.NET Ajax. I can't afford to alway go back an change my code. Another mis by the usoft boys

  • Hi there,

    nice work with the UpdatePanel.
    Nevertheless I have to absolutely agree with Steve. Menu and TreeView controls are probably the first controls I ever want to use within an UpdatePanel. Although TreeView supports Client-Callbacks in a certain way, it does not offer the possibility to actually select a node and causing other actions after that. If you e.g. have a TreeView as part of your navigation and the selection of a node causes the rest of the page to update (sort of frames-replacement) then you always have to refresh the whole page - doesn't offer a real "look-and-feel". Maybe someone knows a workaround for that scenario...(worked perfectly with the Atlas CTPs).
    I hope the number of compatible controls increases with the next release.

    kind regards, Chris

  • Hi,

    How can I modify the output stream in Page.Render() on a page that has an UpdatePanel?

    I am using it to remove/change some tags in the generated HTML.


  • Ryan:
    If your control works, then it works, so of course you shouldn't just change it. The main thing that UpdatePanel provides is functionality for the page developer as opposed to the control developer (though it can be useful for them as well). For example, what if the page developer wants to have a GridView with cool AJAX functionality? UpdatePanel is the answer. They don't need to wait for a new grid that has the new functionality. (Yes, GridView actually has limited AJAX functionality already in ASP.NET 2.0, but it's a bit nicer with UpdatePanel instead).
    I think that in your case all you need to look at is how to make sure your control works well *with* UpdatePanel and ASP.NET AJAX, and not necessarily worry about "converting" it. Still, you might be able to improve your code by using the class structure that ASP.NET AJAX provides, but that's totally up to you and what you think you might save in development and maintenance costs.

    I'm afraid techniques like that don't work very well with UpdatePanel since they conflict with the special format we send from the server to the client during async calls. Have you considered using Control Adapters to achieve some of that functionality?

    - Eilon

  • Hi Eilon,

    Thanks for this post at least I now understand why my treeview \ menu control within an updatepanel now fails to work correctly since the upgrade.

    Note that these were the very first two controls I peronally put into an updatepanel and thought wow !

    From reading your post there must be some workaround that we can do to get treeview \ menu control to register their scripts correctly.

    Any thoughts on how to do this ?

    Maybe create my own control derived from the treeview and manually register the necessary scripts?


  • I have some custom controls I wrote that use:


    to inject some javascript and stuff into page.

    So should I now be adding a reference to the WebExtensions dll and be using:


    If so, is there any reason the ClientScript.RegisterClientScriptBlock? Or should I just always use the ScriptManager from now on?

  • Why are the RegisterClientScriptBlock methods on the ScriptManager so restrictive?

    I have code that uses RegisterClientScriptBlock to insert CSS, but it refuses to accept it because it is not a well formed script block.

  • I have a Master page (with a ScriptManager on it) that allows you to navigate around which changes usercontrols within an updatepanel. But what happens is that each usercontrol (page) registers it's script... and we end up just getting a constantly growing mass of javascript on the page. It is not clearing between each. And I can't seem to find an 'UnRegister' method or something to clear out what's in there.

  • let's see... it is now April 22, 2008.

    it still doesn't work.

    thanks microsoft. thanks a whole lot.

    can you ever do anything right?

  • The example of using a tree view as a menu with an updatepanel is a good one.

    I have a custom control and I am using the updatepanel to change states (hide/display child controls for editing/viewing purposes). I had to put everything inside the panel if I wanted their visibility to change and it's only now that I am coming to the end that I find the tree won't even expand inside the panel. I can't move it outside the panel because I can't then hide it when going into non-editing mode. WHAT AM I SUPPOSED TO DO?!!!

    Time constrained or not, given the number of people who have posted about this across the web, it is not so rare a situation.

    Words cannot sufficiently express how frustrated and annoyed I am.

Comments have been disabled for this content.