Enabling greater control over rendered HTML

Dimitri Glazkov has some interesting thoughts around ASP.NET controls, and the perceived lack of control over the rendered markup and prompted me to respond. To summarize, Dmitri suggests proposes a more generalized usage of adapters that would be an abstraction layer for rendering, and a more flexible mechanism for selecting them. Bertrand followed this up with a post of his own on the level of control over the rendered output where he brought up a range of options from CSS to templates to themes to custom control development as mechanisms for greater control over the rendering. Check out their posts for more details.

In general, I agree with some of the thoughts Dmitri has - the ability to make rendering (and processing postback data etc.) completely pluggable is desired, and would be nirvana to some. I have myself been having similar thoughts as I think about where we should go in the future. At the same time, I am not convinced adapters are the panacea one might be looking for. A key problem with adapters is exposing internal state of the control to the adapter. It is possible to expose some state, but the moment an external developer decides to write a new adapter, it is likely they will find they need some piece of internal state information that has not been exposed to them. The adapter model essentially creates a parallel inheritance hierarchy, which doesn't work all that great for extensibility in the long run.

There are a number of other things to consider and balance with the ability to have greater control over rendering as well - namely simplicity, and performance.

The Login control is a great example of these needs balanced. The login control on the page, and very simply set up some properties to customize the look and behavior. The result is a fully functioning login scenario with some control over the behavior, and modest control over the look and feel. This sort of functionality is absolutely essential. Requiring the page developer or designer to select an adapter or a theme or anything else would be an obstacle in the control's usability. However, the control does allow the page designer to peel a layer away and completely customize the content using a template. The templating approach leverages the compositional paradigm, which is easier to understand than the adapter model. One important implementation detail in this approach is how the Login control uses the content of the template. It doesn't look for specifically a control of type TextBox. Instead it looks for a control that implements ITextControl. This allows the page developer to use a custom text-box control if they prefer that over the standard one. The Login control's default rendering can also implemented as a template - so the decision to use a custom template does not come with a significant performance penalty.

Combined with themes, the Login control metaphor is pretty compelling, and goes a long way in providing greater control over the final rendering. We do need to apply it more generally where appropriate.


One place where ASP.NET does not offer a whole lot of control over rendering is in defining markup structure, especially in repeating scenarios, such as in TreeView or GridView. The logic to generating this repeating structure is encapsulated deep inside the control, and isn't customizable or replaceable beyond the set of properties provided by the control. Templates are great to customize the content shown within a structure, but do not provide the ability to specify structure. I think this is an area where "adapters" and "structural templates" might infact be extremely useful, but there are a number of problems to solve. Some of my thoughts in this area have been inspired by new concepts built into Avalon - a great avenue for some future prototyping and blog posts.


Another interesting point Dmitri brought up that hasn't been discussed much is the possibility of distinct tool experiences for developers and designers. I do think one of the fundamental benefits of server controls that remains largely untapped is in the area of tool experience. By virtue of being "living" entities within the design surface, server controls have the ability to offer different experiences based on the context in which the design surface is being used. More thought on this end needs to be given as well.