While building a new control on top of the ASP.NET 2.0 framework, I noticed there have been some changes. Using the new framework it is far easier to implement new server controls and designers. I thought it would be nice to write a 5 part article about the development of a designable server control. Various degrees of design ability will be provided for this new control, called the DuoView. The DuoView is a simple templated control which was created specifically as an example for this article. The control will have four designers, each one providing a little piece of the design-time puzzle. The following overview displays what will be implemented in each part of this article.
- The DuoView control, this is the templated control which will be designable in Visual Studio 2005.
- A simple designer, a minimalist designer for the DuoView control.
- The rendering designer, rendering the control on the designer surface.
- Smart-tags, using smart-tags to enhance the user experience.
- Editable regions, allow the templates to be modified without explicitly entering the edit mode.
Every new designer created uses the code provided by the previous ones by using inheritance. But before developing a designer, the control needs to be created. And that is exactly what will happen in the first part of this article.
Introducing the DuoView control
The first thing that is needed when developing a templated control designer is the templated control itself. For use in this paper a simple templated control has been developed, the DuoView. It looks and feels like the new
LoginView control found in the ASP.NET 2.0 toolkit, but the mechanism used to switch the displayed template differs. Unlike the
LoginView, which activates a template based on the authentication state of a user, the
DuoView gives the developer the ability to choose the active template. The control is made up of two templates. The template to display is indicated using the
DisplayMode enumeration and the
ActiveDisplayMode property, which can be set at runtime. The value for the property is stored using control state which allows the state to be remembered during postbacks, even when the use of ViewState is turned off for the control. The code in the following figure displays the switching logic.
enum DisplayMode{FirstTemplate=0, SecondTemplate=1};
public DisplayMode ActiveDisplayMode
{ get { return _activeDisplayMode; } set { if (!Enum.IsDefined(typeof(DisplayMode), value)) { throw new ArgumentOutOfRangeException("value"); } if (value != _activeDisplayMode) { OnViewChanging(EventArgs.Empty); _activeDisplayMode = value; ChildControlsCreated = false; ClearChildViewState(); OnViewChanged(EventArgs.Empty); } } } |
| Figure 1. Template switching logic |
When changing the active template it will have to be re-instantiated and added to the control collection of the DuoView. The actual instantiation of the template isnt performed by this property. The template is instantiated on demand when accessing the
Controls collection for instance. The
ChildControlsCreated flag is used to indicate that instantiation is required. The
ActiveDisplayMode property just toggles the flag and uses a simple event mechanism to notify when the active template changes.
The active template is instantiated using an override of the
CreateChildControlsmethod. When called, the template indicated by
ActiveDisplayMode is instantiated, and the resulting
Control is added to the
Controls collection of the DuoView. Access to the right template is provided using the
ActiveTemplate property.
ITemplate[] _templates = new ITemplate[2]; protected virtual ITemplate ActiveTemplate { get { return _templates[(int)_activeDisplayMode]; } }
protected override void CreateChildControls() { Controls.Clear(); ITemplate template = ActiveTemplate; if (template != null) { Control control = new Control(); template.InstantiateIn(control); Controls.Add(control); } ChildControlsCreated = true; } |
| Figure 2. Instantiating the right template |
That’s it for the DuoView control. All the rest is the usual boilerplate code for a templated control. The interesting part is ahead, implementing the designer. This part will be implemented in the next part of this article, which I will post next monday (26 aug 2005).