And while I don't have enough insight into exactly HOW Sitecore ties in to the ASP.NET lifecycle to determine exactly WHY this setting is needed, I can however tell you what happens if you don't fully control it.
Say you have a control, where you drop in an ASP.NET ListView Control. Or a GridView control. They'll appear to work fine at first, but you'll quickly notice that paging and viewstate is acting up a bit on your controls.
The fix for this is easy, and as far as I know this is well known by Sitecore Support. Add your controls to this - almost black magic like - web.config setting, and you're set :-)
Add System.Web.UI.WebControls.ListView, and System.Web.UI.WebControls.GridView to this collection if you find paging, viewstate or other things "that normally works" doesn't.
I don't know when this setting was introduced, or even IF there is a reason Sitecore doesn't include these common controls in the list. Maybe there's a negative effect on performance or otherwise.
Searching on the web only produces this one link (searching on SDN, two results but similarly without explanation), and that doesn't tell us anything else than the config setting was apparently introduced in Sitecore 5.3.2 071220.
This is a truly horrible problem! Thanks.
I originally thought that there was something wrong in my code. I had no reason to believe that Sitecore could have had a hand in it. You've obviously enlightened me!!
You have to wonder why they didn't put a comment in the web.config or at least add GridView and the other affected controls to the TypesThatShouldNotBeExpanded list... ;< Nasty nasty nasty bug.
Well.. According to information that sits behind the password shield on http://sdn.sitecore.net/SDN5/Forum/ShowPost.aspx?PostID=14956, it's not really a bug. It's more a sideeffect of the way Sitecore hooks into the page lifecycle - something I know almost nothing about as it is not documented and most of the code sits behind obfuscation. Since this is very core functionality to Sitecore I guess this makes perfect sense, to protect rights and patents and so on.
I agree though, a heads-up and perhaps having the most commonly used ASP.NET types added to the list by default would be nice.
Post a Comment
Links to this post:
Create a Link