What level of control do you need over the rendered HTML?

I'm answering a post from Dimitri Glazkov here. Dimitri tracked this back to my post about UI reusability. It's probably a good idea to read his post before you go on reading this if you want to understand what this is about.
 
In an architect's ideal dreamworld, I'd say you're absolutely right, Dimitri. In the real world, though, I'd mitigate this.
After all, that's what server controls are all about: abstracting the HTML rendering and substituting higher-level abstractions for it. The controls are not ethereal entities, and they need to have some level of control over their rendering to actually work. If you want to have complete control over the rendered HTML, the only thing you can do is output it yourself, and you're back to classic ASP (or PHP). So we should probably be somewhere between complete control and pages made of only server controls.
 
I'm sure you're aware of this, but I'll say it anyways for your readers and mine who may not be as advanced as you are in ASP.NET.
 
There are a few things you can do to control the rendering of ASP.NET controls:
- Use CSS (works with any server-side web technology)
- Use styles (and in particular their CssClass property to link them to CSS) (v1)
- Use templates, which give you total control over the HTML that's rendered by some parts of the controls (usually the ones that are the most visual and are not vital for the control to actually work). Templates rule! (v1)
- Know the control set: there is a fine granularity over the control you can have over the rendering just by choosing the right control. For example, DataGrid, DataList and Repeater are similar list controls that give you more and more control over the final rendering. (v1)
- Develop your own controls, from scratch or by inheriting from an existing one. This way, you can override part or all of the rendering code. (v1)
- Use themes and skins to isolate the general presentation of the site. Themes are more or less equivalent to server-side CSS: they act at the same level of abstraction as controls, and enable to set any property (hint: even TEMPLATES) of any control, site-wide or based on a skin ID. Themes are very easy to write as they have the same syntax as a page. (v2)
 
About adapters, you're right in mentioning that there is a yet unfulfilled potential there. But it may be not in their implementation but in their very use. They may be used for something else than just device adapting. I'll try to blog on that if I have time to experiment with the concept a little more.
 
Your point about the three roles in the designer is a good one and there may be things more or less along these lines in Orcas. But if you look at it as it is currently, we're already kind of there... You have the visual design view, for designers, you have the HTML view, for what you call the prototype, and you have codebehind for the actual plumbing of the page. Yes, the first two actually act on the same thing, but at a different abstraction level.
I do not understand your third role, though: why would theme development be the role of an advanced developer? I would have given this role to the graphics designer. Well, at least, the designer can determine the general look of the page and a developer can transform that into a theme.

4 Comments

  • I am not sure that it has to be an ideal world for the clean separation to work. Indeed, the concept needs refinement, but the core of it is good, methinks. Imagine something like this: an adapter pattern with decoratorish tendencies applied to rendering of a control.



    This way, a control only represents the data and manipulation with it. It does not emit any markup, but it does know how to retrieve, process, and update information.



    Parallel to it is an adapter, which doesn't know how to do any of the above with the data, but it does know how to query control's properties and how to render it using markup.



    Yes, this means that for each control there has to be an adapter, but it is a compromise that we ought to be willing to make in order to escape hard-coding HTML into control's functionality.



    We are essentially continuing the Page Controller paradigm into the controls, rather than stopping at the level of the page.



    As a possible implementation scenario, an adapter could simply spit out control's properties as XML and allow developers write XSLT to transform it into HTML.



    You could also easily imagine an adaptive control, which attempts to render properties of any control -- this is not necessarily a production environment-type trick, but something that could be useful to render orphan controls -- those without a corresponding adapter.



    This is why my third role is for advanced developers -- creating adapters would not be something that a designer would do. Following requirements of a designer, yes, but probably not a designer him/herself.

  • Bertrand, I think your assertion that most controls are UI elements is correct and valid. There are a couple of "buts" though:



    1. There is definitely a trend into making controls more than that -- look at the "login" control in Whidbey, for example. For all I can see, it's a little self-contained application.



    2. Being a UI element doesn't mean that controls have to emit the actual markup. That is why I am advocating a layer of abstraction -- to provide capability to translate UI into whatever flavor of markup (even XAML, perhaps?) is required.



    3. The mentioned above layer of abstraction has to work both ways -- in fact, it should be the purpose of translating results back and forth. The control doesn't need to worry about whether this was a POST request, a GET request, or an asynchronous WS callback of some sort. The control doesn't need to worry about how it would be rendered. All it has to do is to advertise to the rendering layer that it will take a one-line input of plain text titled "Login", a one-line masked input of plain text titled "Password", and a "Login" button. The control performs validation and reaction to the input. The rendering layer makes it look "pretty". I am simplifying, of course.



    I realize that what I am proposing is veering off from the current concept of a Web control, but hey, that's what this communication thing is for -- thought generation :)



    As far as performance is concerned, I understand your point. Balancing functionality and performance is a tough act. I do believe, however, that there are ways to minimize impact of an abstraction layer on overall application performance. You guys wrote a book on this stuff :)

  • By the way, I love it when the comments become larger than the original message. It proves that the subject was well chosen :)

  • From Nikhil's post: "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."

Comments have been disabled for this content.