blog
Application Development, Insight Article, Interaction Design, Technology, Web Development, ASP.NET, ViewState
Dynamic Web Controls in ASP.NET March 16th, 2010
ASP.NET’s ability to populate controls into pages at runtime is a very powerful feature. Instead of knowing exactly what the structure and content of a page is at compile time, webpages can be made to be more programmatic, adjusting to situations on the fly. There are certain amazing things that can be done with CSS, such as controlling the styling and positioning of webpage content, but an ASP.NET programmer can literally add and remove controls on the fly as they see fit.
For those of us who subscribe to AOP (Aspect-oriented Programming) methodologies, this is a dream come true. Presentation can be further separated from business logic, the business logic gains control over presentation without any actual HTML work, and there’s a perfectly logical way to implement a factory for webcontrol creation. For the truly power-hungry developer who will stop at nothing, the entire schema of a webpage can be pushed into the data layer.
Unfortunately, if you want to gain this power, without giving up certain other useful ASP.NET features (primarily ViewState), there are some things to tiptoe around.
The life of an ASP.NET webpage:
- The page is requested.
- Some of the page’s properties are set (such as Request, Response, and IsPostBack).
- Page_Init() is fired and the page’s controls are loaded.
- If it’s a postback, the page’s controls’ states and ViewStates are loaded.
- Page_Load() is fired.
- Any validator controls in the page are fired.
- Any unresolved postback events are acted upon.
- The page is rendered and the page’s controls’ ViewStates are saved.
- Control of the page is given to the client (internet browser).
When ASP.NET loads ViewState into its controls, it expects the page’s control structure to be exactly what it was when the ViewState was last saved. ASP.NET saves the ViewState of a page in a lightweight serialized form that depends directly on each control’s position in the ViewState tree – if controls dynamically change position, are added or deleted, or anything else, the ViewState can be corrupted.
An important thing to note is that the page’s controls are created when Page_Init() is fired, then their ViewStates are loaded, then Page_Load() is fired. Therefore, dynamic controls must be created in Page_Init(), so that they exist when the ViewState is loaded. A very common mistake is to create dynamic controls in Page_Load(), but as you can see from the ASP.NET lifecycle, this should not be done.
Mixing of static and dynamic controls
The ViewStates of ASP.NET pages run into really big problems when you have complex arrangements of dynamic and static content. For example: a page with a static panel and a static placeholder that dynamically loads in a user-defined control will wrap a statically defined GridView (yes, I have run into this exact situation). When you have mixed dependencies between dynamic and static controls, ASP.NET’s ViewState loader is unable to reconstruct the page.
When you get into the realm of having fluid pages that truly warrant dynamic controls, it’s important that only the base layer of the page be static. Dynamic controls should not have static controls as children if the ViewState is being used. When designing a site, keep these things in mind, to prevent future redevelopment.
Other considerations with dynamic controls
Because of the way that the ViewState is handled, dynamic controls will need to be created into the page in a consistent manner – the ViewState tree structure needs to be preserved. If there’s a need to change the structure of controls as they exist in the ViewState, the controls should be rebuilt in Page_Init() as the ViewState expects, then the control structure should be changed in Page_Load() or in event handlers. That way the control structure changes after the time the ViewState is loaded, and before it is saved for the next postback. Another option is to redirect back to the page, which will clear the ViewState, but if you have any other information you need saved, you’ll have to save it in the QueryString.
Conclusion
The ability to build webpages with dynamic controls in ASP.NET is a powerful ability for the power-hungry developer. On the plus side, it opens up possibilities for creating applications that are geared heavily toward code-reuse, AOP, and event-driven adaptability. But beware what you ask for – going down this road drives you deeper into the innards of the .NET Framework, and requires a deeper level of expertise.

No Comments