A piece of information that I’ve tended to gloss over until now was that during a partial postback by means of an Atlas UpdatePanel, the server life cycle goes through a normal postback life cycle. I never gave this much thought until I was considering what this meant for performance. Were all of my controls re-rendering even if they weren’t contained within an UpdatePanel that was set to update? How did the server side Atlas framework know to only send the HTML for the controls that were contained in an updating UpdatePanel down stream? Was there a way to make my code perform better knowing that I was working within the Atlas framework?
The simple answers: Yes. The framework is smart. I’m not too sure.
The more complete answers ….
All controls are participating in the postback in normal life cycle fashion. Their viewstate is loaded; their controls created; their data, bound. The major difference occurred when it came to any of the render methods (BeginRender, Render, EndRender, AddAttributesToRender, etc.) that normally had an HtmlWriter parameter. Here, in one of the previously stated methods (e.g. Render) an updating UpdatePanel used a normal HtmlWriter parameter as expected. However, in the same method within a control that wasn’t within an updating UpdatePanel, the parameter was of type Microsoft.Web.UI.DummyHtmlTextWriter. Whoa … what this means is that there are two HtmlWriters. Whether you are going to be re-rendered down to the browser or not determines which HtmlWriter is used. (BTW, thank Microsoft for creating the DummyHtmlWriter type. I’m pretty sure that they could have used a NullTextWriter when they didn’t want a control’s output to be sent to the browser, but if nothing else, the DummyHtmlWriter makes it really clear that this control isn’t actually going to be sent to the browser.)
The next logical question I had was why Microsoft didn’t program it so that if a control wasn’t going to be re-rendered and sent down to the browser it never entered the Render phase and therefore eliminating the need for the new DummyHtmlWriter type? The answer actually came from Microsoft because I was stuck on this one for a while. The reason for this was because the EventValidation hashcode is created in the Render method and when a page has EventValidation enabled (as all pages do normally and it’s the default) the base Render method must execute at the appropriate time in order for this hashcode to be created. (As a side bar, to understand the Event Validation, see K Scott Allen's Blog Entry on Event Validation or Shawn Burke's Blog Entry on the Cascading Dropdown Control, but it pretty much prevents unauthorized postback values.) Therefore, in order for a page’s EventValidation hashcode to be correct, all of its child controls must execute their render methods to create their hashcodes which can be passed up the chain and hence the reason that all controls must be re-rendered.
Up until now, I’ve answered my first two questions, but is there a way, knowing I’m working within the Atlas Framework, to program slightly differently to make my code run faster? Truth-be-told, I don’t see too much. There’s a basic knowledge of knowing that I’m in a postback and therefore loading or not loading data as appropriate, but other than that I’m not sure.
A question remains … I have a drop down with the values 1, 2, 3. They are rendered initially, but not re-rendered on a postback. An UpatePanel causes a partial postback (does not contain the dropdown). Will I get an EventValidation exception if I perform a normal full postback? So normally if I perform a postback I would have to re-render the dropdown either from ViewState or from my initial data in order for the dropdown to display. But, if I perform a partial postback my dropdown values will still exist on the page because I’m not replacing the Html associated to that area of the page. But the page’s EventValidation hashcode won’t contain the dropdown’s values because they were never re-rendered. What happens when I perform a normal postback?? I’ve been sitting in front of my computer on an awesome Sunday for way too long to test this right now, but I’ll post a follow up soon.