Let me first start by saying that ASP.NET is an awesome framework. It is now my primary development platform and it is a joy to work with. It brings to the table something that is not built-in in most of the scripting platforms — a pattern-driven development paradigm, based on “Page Controller” pattern, mentioned in Martin Fowler’s “Patterns of Enterprise Application Architecture” book.
Unfortunately, not all is well in the current (ASP.NET 1.1) model. One of framework’s most significant problems is that the rendering of a control is tightly bound to its implementation (I first mentioned this in one of my earlier posts). In my book, mashing functionality and presentation together is never a good thing. While the initial results may end up looking shnazzy and easy to slap together, the long-term liability of not following the rules will sooner or later catch up with you.
The way Controls are implemented, Render is one of the methods of the control, encouraging (forcing sometimes) developers to embed HTML and CSS code into the actual controls.
Now, from the designer perspective, this effectively shreds the HTML output into a number of small nuggets that are hard-coded into each of the controls. With proliferation of third-party controls, the control of look and feel of the site is placed firmly into the developer’s hands, leaving designer with only maybe a banner and a footer to play. That’s not a very good proposition.
As any good book on Web process methodology would suggest, there are many roles involved in the process of building a site. If you work for a large company that means that you have a team of people working on the project. If you are working alone, that means you have to wear many hats. It does not mean that you have to forego those roles and just hack your site together.
He who wears the developer hat should not be concerned whether the box corners are rounded. He who wears the designer hat should not be concerned whether the box with rounded corners is a control or just a literal markup, emitted by a larger control.
Whidbey made a few good steps forward with the introduction of Themes, but from what I understand, the Themes stop short by simply being a CSS style manager, not a way to manage the actual markup rendering of controls.
Then there is a new layer of abstraction for rendering in the form of Adapters, but they are somewhat locked into a special case of browser/browsing device support. I also have doubts that Adapters will be powerful enough for site of any reasonable complexity without the support of more flexible control selectors.
This maybe too late for ASP.NET 2.0, but if I were developing the next iteration of the framework, I would do the following (this is a first stab, just trying to give a sense of direction):
- Elevate Adapters to the full-citizen status by making them the de facto rendering layer for controls (not just the “special“ case rendering)
- Integrate Themes and Adapters so that the markup can be controled completely by a Theme.
- Take the .skin files out of the theme and into its own Skin category — skins control how a Theme applies to a particular application. In effect, themes become truly interchangeable. Talk about an ISV market potential here!
- Provide more flexible (maybe even CSS2-style) selectors for Skin controls.
- Develop several built-in Themes for the developers.
- Split the current development surface of Visual Studio (the “design“ view) into three views along the lines of Web process roles.
- The first new development surface will be the “proto form“ view, for developers. You can drag and drop controls on this surface, arrange their order and parameters, but not the visual style.
- The second development surface will be the designer view, which would allow designers to visually develop application skins (basically, connect Theme elements to actual controls in the application).
- The third development surface will concentrate on the actual development of Themes and be focused toward more advanced developers.
By creating a well-defined layer of abstraction for rendering, the framework would create a more organized and process-oriented approach to Web application development and most importantly, a way to affect the look and feel of your application without having to change its code.
What’s interesting, if all of this is in place, the development paradigm will not become more complex for beginners and Mort users — it will actually be easier. Instead of tweaking the colors on each individual controls, they would have capability to paint their application with large brush strokes, using themes. And if they want to re-paint — just find another theme, pick out cool gadgety thingies that blink and roll, and brush away.