Categories
perspective

Dynamically Nested Controls ASP.Net

The solution seemed simple enough and what’s more, it should have been a straightforward implementation. Should have been. After one or two false starts, we settled into an approach until we hit the ubiquitous viewstate issues. It’s a silly problem to be having really, given that every asp.net server control automatically manages its own state. True, there are constraints and conditions, nonetheless, the theories are not rocket science.

The page dynamically loads a “layout” usercontrol, depending on user context. This layout dynamically nests a “view” usercontrol, again depending on module within the application. This view then dynamically loads one of n “function” usercontrols on a postback. And therein lies the rub. This function itself posts back data from it’s children, one of which is typically a repeater or other custom usercontrols. Further, each repeater item may contain N server controls. After the postback, the page loads and all the viewstate across all the dynamically nested controls and their children load perfectly, viewstate intact. Simple.

The concepts: each server control maintains its own viewstate [good encapsulation]. The viewstate is heirarchically defined and processed at specific points [good definition]. This is a recursive situation, so if it works for one layer, it must work for N layers. The problems: confusing my requirements with another blog’s requirements, vague newsgroups and technical expressions, sometimes ambiguous documentation and a lot of CheeseFactor :).

After a fresh restart, simplifying the problem domain and applying recursive heuristics the solution is indeed simple. And as simple as they are, i often wonder why/how/where the connection points get missed? Methinks the language of function within the education process is not as sufficient as it could be, but that’s another discussion. So, in summary:

• Always load your dynamic controls, even on the postback. The (!IsPostBack) is not an decision you can use for deciding to load controls dynamically. Use that for binding data.
• Page dynamically loads control inside OnInit(). By the time you hit Page_Load, it’s too late for anything viewstate related, particularly when we’re looking at nested, nested controls.
• Give your dynamically created controls a unique ID. Better for debugging so instead of trying to figure out the tree through reading _ctl1, _ctl2, etc.. The tree now reads as Main, Layout, View, Function, etc… Write code for programmers, not for computers.
• Immediately add the dynamic control to the tree before setting any properties on it.
• With dynamically nested controls, follow similar principles as for page. Don’t dynamically load a nested control inside ControlLoad. Too late. CreateChildControls works much better.

Following these guidelines, your nested, nested controls maintain viewstate perfectly with no additional plumbing. Including all repeater items containing additional server controls and other custom usercontrols.

Tools, Ideas and References:
Google
Concrete Mathematics, A Foundation For Computer Science, Graham, Knuth & Patashnik
dotnet247.com
Authoring Custom Controls
Dynamic Web Controls, Postbacks, and View State By Scott Mitchell

2 replies on “Dynamically Nested Controls ASP.Net”

Comments are closed.