Blog Home  Home Feed your aggregator (RSS 2.0)  
Lack of Extensibility in some parts of ASP.NET - Manuel Abadia's ASP.NET stuff
# Thursday, August 16, 2007

Today is my “official rant day” so I had to post this. The Parameter class was something introduced with the new data binding infrastructure for ASP.NET 2.0. There are some classes that derive from the Parameter class like ControlParameter, CookieParameter, SessionParameter, etc. providing the developer with a good set of parameters to play with. Also, you can derive from the Parameter class in order to create your own parameters. Everything looks cool and extensible.
What is the problem? Imagine you create a new class, MyParameter, that inherits from the Parameter class. Probably, you will want to use that parameter in other places, probably in a ParameterCollection. However, if you go to the designer and try to add a parameter to a parameter collection you won’t see your parameter, only the predefined parameter types. You can expect that, as you haven’t code anything for design time, but you hope that it will be easy to extend the default parameter editor to support your parameter.

The surprise come when you try to extend the default parameter collection editor. The ParameterCollectionEditor delegates all the functionality to the ParameterEditorCollectionForm class, an internal class. The ParameterEditorCollectionForm uses the ParameterEditorUserControl class (this is a public class) to edit a parameter.

The ParameterEditorUserControl contains a UserControl for each type of parameter it supports. The method InitializeParameterEditors and CreateParameterList are private,  so you can’t extend it in any way. When you change the type of parameter you are editing using the combo box, the SetActiveEditParameterItem method gets called to set the proper editor for the current parameter. This method contains some if else statements to select the proper editor based on the current parameter. Of course, the SetActiveEditParameterItem method is private too, so there is no way to extend the parameter editor in design time.

So, as you have seen, just to add design time support to another parameter you have to rewrite a lot of classes. With just a few tweaks to the existing classes, you would only need to override a couple of methods to point to your editor for the new parameter class you have created. If a class is a clear candidate to extending like the Parameter class, the design time related classes also have to be extensible. It is so frustrating to see this in several places...

It would be cool to have several ASP.NET team members to study how to redesign their code in order to make it truly extensible.

Thursday, August 16, 2007 4:54:23 PM (Romance Daylight Time, UTC+02:00)  #    Comments [2]   ASP.NET  | 
Thursday, August 16, 2007 7:39:20 PM (Romance Daylight Time, UTC+02:00)
I absolutely agree, I ran into this exact same issue recently, and went through the same thought processes before giving up in frustration. What's worse is that the designer actively works against using other types of parameters by removing them if it is used.
Rather than using custom parameters I now use a code expression builder to set the defaultValue of regular parameters as described here:
It works really well, and is a very simple elegant solution.
Friday, August 17, 2007 8:37:09 AM (Romance Daylight Time, UTC+02:00)

thanks for the link. The code expression builder is very useful and I will use in my own projects. However, the new parameters are for one of my components so I'll have to add full design time support for them sooner or later :-(
All comments require the approval of the site owner before being displayed.
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview
Copyright © 2020 Manuel Abadia. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.