| Join
Rate It (2)
Last post 04-18-2007 12:51 PM by raja.krish. 46 replies.
Sort Posts:
Oldest to newest
Newest to oldest
Intro:
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..
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.
Issues:
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.
Thanks,
Eilon
Giving this a bump. I'd love to here specific feedback on this subject.
reply to bump.
Hi Eilon,
Just trying to digest all this stuff. It's not that I'm not paying attention. Still trying to figure out how to make the left and right side of my rounded corners from stopping disappearing. :)
Eilon.
So does the part about 'WebParts' mean that things that worked in previous version of Atlas won't work now? We had built some WebPart functionality that worked within an UpdatePanel and we're now concerned that this won't work once we upgrade to the Beta 1 release.
We're already getting errors with references to the Microsoft.Web.UI.Controls.WebParts namespace.
Hi Michael,
I believe we will still have WebParts support in the CTP (the Preview DLL), but probably not in the main Atlas DLL. I'm not sure exactly what we had in the beta but I think the RC will have that support as it was in the previous CTP.
Hello Eilon,
can this be the reason (registering the script through the Manger) that no Extenders from the Toolkit are working on the first call inside WebParts that contain an UpdatePanel? After a post back (e.g. simply minimizing/restoring) the WebPart they work.
My control hierarchy:... WebPart - UpdatePanel - (e.g.) HoverMenuExtender
ThanksFlaxon
Hi.
I think it's a good change, since it simplifies the UpdatePanel work guessing what it needs to send, although we will need to code more and provide specific support for atlas.
But it's a better model. I never experienced any problems like those you said, but until now, we used to create controls and it just worked with atlas, now we need to implement things, test and ensure it has been created to work with ajax.
Now, I know it is still a beta, but do you think that the final MS ASP.NET Ajax will have many other breaking changes what happened from CTP to Beta?
Thanks.
IScriptControls (such as extenders) had many issues in the beta. We are planning on having that fixed for the next release.
The amount of changes from here on out will be a lot more limited. Of course there will be some breaking changes but only where we felt it was really necessary. The main cause of changes between the CTP and the beta was design changes, and those in turn create a lot of other changes. In subsequent releases we don't plan on redesigning anything, but things such as method names, namespaces, and slight behavior changes should be expected.
Is there going to be a certification test for 3rd party custom control vendors so that we can be assured that they place nice with Atlas? Something like the Windows Driver Verification stuff? It's really important that not only does a vendor claim that they are Atlas compliant, but Microsoft says, "yes, they are Atlas compliant. Go ahead and use it."
Some seriously awesome stuff went into the Beta release. Sweet.
Thx, Joel
hi,Eilon:
As you said, the mechanism is different now.
So can you tell me how to use the UpdatePanel now if the UpdatePanel can work in another mechanism.
Are there some links?
Thanks!!!
Here's a new article on how to write controls that are compatible with UpdatePanel without having to link to the Microsoft ASP.NET AJAX assembly:
Here's a summary of WebParts support in Atlas 1.0. There are three different WebParts features:
Cross-browser drag and drop is enabled by using the WebParts controls in the AJAX “ValueAdd” CTP. This was working in July CTP, and should still be working in the current release. This will continue to work in the AJAX "ValueAdd" CTP.#2 is implemented by wrapping the WebPartManager and WebPartZones in an UpdatePanel. This was partially working in the July CTP. It is not supported in Atlas 1.0, in either the AJAX “Core” or the AJAX “ValueAdd” CTP. It should be supported in Orcas.#3 is implemented by placing an UpdatePanel inside a WebPart. This was also partially working in the July CTP. This is fully supported in the AJAX 1.0 “Core”. It should work with either the ASP.NET 2.0 WebParts controls, or the AJAX “ValueAdd” CTP versions of the WebParts controls.
Hope this helps,-Mike
Nice work Eilon, the changes sound great and I look forward to implementing them. Now you just need to add the ability to customize how the UpdatePanel is rendered. Being limited to either a div or span is pretty crummy. I've built upon the existing UpdatePanel to add this functionality for the time being, but it would be awesome if it came standard.
I look forward to hearing all new developments.
Hello Mike,
Thanks for bringing light into this, but I have two question regarding #1 and #3:
Regarding #1: Since DnD is not working for me with the beta 1: Can this be the issue: Reply from 'chenriks' in
Regarding #3: As I posted in the control extenders from the Ajax Toolkit are not working inside a WebPart. I assume this is because the ScriptManager does all the control registration in the Page.PreRender event (as posted from 'sburke_msft' in). Because the WebParts are added very late in the pages life cycle also during the PreRender event, the extenders are not registered correctly on first load? After a (async) post back the extenders work!
An answer would be highly appreciated since weather the Tollkit team nor anbody in this form has already given me some feedback on this.
We have an application that is close to release, however we have been strugglying with the lack of documentation - primarily in terms of best practices.
We use a menu in an update panel.You mentioned that the scripts are no longer automatically registered for the menu. We have put a lot of effort in getting our app ready and this is a major stumbling block.
Is it possible to wrap the menu control and register each link with the a scriptmanagerproxy? How would this best be done? We really appreciate your opinions!
Advertise |
Ads by BanManPro |
Running IIS7
Trademarks |
Privacy Statement
© 2009 Microsoft Corporation.