Do You Value Design Time Support?

Good design time support for your components may seem like a nice exercise but otherwiese unnecessary and generally not worth the money (especially if it’s the customers money). After all, design time support plays no role at runtime when the real ROI is realized, right?

I think it comes as no big surprise if I tell you: I don’t agree. Design time support elevates quality! It guides you through complex tasks by wizards (would you type in all the parameters for a complex data source control?), it may provide default settings (effectively speeding up the input), it offers selections of valid values (effectively reducing typos), it validates parametrizations (before inconsistencies cause runtime errors), and last not least it instantly visualizes the information that is important.

Thus, good design time support reduces complexity, speeds up the development process, eliminates bugs. It even steepens the learing curve for new team members. To put it short: Good design time support saves money!

Well, design time support still needs investment. Granted, Visual Studio already offers a great deal of design time support (the principle holds true for any other IDE as well). Visual designers for windows forms, ASP.NET, XSD, etc., the property grid with its implanted comboboxes and dialogs, various wizards (e.g. the already mentioned wizards to set up data sources), etc.. But there is still room for improvement, most obviously for your own components but for existing ones as well.

The extension points ASP.NET and Visual Studio offer are manyfold:

• Your derived control could overwrite standard methods (like Render()) and change its behaviour at design time.
• TypeConverters can be used to restrict the range of valid property values and to show selection lists or dialogs from the property grid.
• Designers can be used to plug into the Visual Studio designer infrastructure and change and extend the design time experience of controls in several ways (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/custdsgnrdotnet.asp).
• You can directly access the Visual Studio design time services. 
• Various interfaces have design time meaning as well as runtime purpose, e.g. ICustomTypeDescriptor, ITypedList, IDataSourceSchema, etc..
• You could write your own root designers for whole files (definitelly a more complex task to to).
• You could use Domain Specific Language Tools: http://msdn.microsoft.com/vstudio/DSLTools/.
• You could host designers in your own application (see http://msdn.microsoft.com/msdnmag/issues/06/03/DesignerHosting/default.aspx).

See, there’s a multitude of opportunities for improvement. A word of warning, though: the Visual Studio design time infrastructure is quite complex. Unfortunatelly it lacks a bit of documentation in certain areas (this has become better with Visual Studio 2005 but there is still a lot room for improvements – or perhaps a book of 1000 pages or more, no kidding).

Concrete example:

Since I allways try to mix bits&bytes with higher level assessments and opinions I guess I’ll have to provide some code, right? OK, let’s have a look at our old friend the data source. Consider the following page within the Visual Studio designer:

A perfectly valid page – and yet it’s totally irrelevant for real world pages. The data source controls are arranged directly beneath the controls bound to them, thus they spoil the HTML design. So once you start using the designer as HTML designer the first thing you will do is to move them out of the way. (You could tell Visual Studio to hide them, yet who would do that?) I placed them at the bottom in a panel control (set to invisible and marked with background color):

Next: Real world pages occasionally use one or two data controls more than shown here. Say about 12 to 20. (That’s not exaggerated. Think of a company page in a CRM system with state, country, region, primary contact, assigned sales person, primary address, assigned industry type and subtype, … . And that’s only the data area.) By the way, that drop down list over there…, could you please tell me which data source control was again filtered by its selected value? Hey, just click on the data sources, one by one, and have a look at the properties…

Too bad. The property dialog doesn’t tell you, just go to the respective dialog. About 12 to 20 times… .

I guess you get the idea. Now close your eyes, lay back and imagine a peacefull world, without environmental pollution, and a dsign time appearance that instantly tells you what you want to know.

Well, mankind being what it is I cannot help with peace and pollution, but here’s my solution for the page: Derive your own class from the data source control class of your choice and attach a designer class. This designer class will be asked by the Visual Studio designer for a design time HTML representation of the control:

[Designer(typeof(MySqlDataSourceDesigner))] public class MySqlDataSource : SqlDataSource { public MySqlDataSource() { } } public class MySqlDataSourceDesigner : SqlDataSourceDesigner { public override string GetDesignTimeHtml() { return DesignerHelper.CreateDesignTimeHtml(control); } }

Given the right implementation the outcome will satisfy the initial demand:

No magic, all well documented, you just have to do it.

Let’s get that straight: Nothing has been won by this code in terms of functionality. (Don’t get carried away with this in front of your customer, he probably won’t understand the value of something that doesn’t add functionality.) What has been gained is instant information. I have all the relevant information right bevor my eye and can even highlight special things (as demonstrated with the ID in red). Add warning or error feedback and no parametrization error will stay unnoticed anymore.

OK, that’s all for… What? … I forgot something? … What source? … Ah, that source. But only on your word that you won’t hold me accountable for any bugs! Here it is: DesignTimeSupport1.zip (download and rename to *.zip).

That’s all for now folks,
AJ.NET

Advertisement