What level of control do you need over the rendered HTML?
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
- 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
- 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.