Question

I am creating a couple different custom controls, each of which implement different base controls, but they all will be getting some common properties and functionality added to them. So I was wanting to place those common properties (with their common getters and setters) and the duplication of the functionality into an abstract class. But I’m having a hard time wrapping my head around how to architect the controls and its bases to allow the implementation of both my abstract class and the base web control I’m building on top of. Can anyone help me out?

Some of the controls I’m building

public class AssetDataStringControl : TextBox
public class AssetDataIntegerControl : TextBox
public class AssetDataUrlControl : CompositeControl
public class AssetDataListBoxControl : ListBox
public class AssetDataDropDownControl : DropDownList

My abstract class

public abstract class AssetDataInputControlBase<T> : Control, 
    IAssetDataInputControl<T>
{
    protected virtual int AssetId
    {
        get
        {
            object o = ViewState["AssetId"];
            return o == null ? 0 : (int)o;
        }
        set { ViewState["AssetId"] = value; }
    }

    protected virtual AssetStructureField StructureField
    {
        get
        {
            object o = ViewState["StructureField"];
            return o == null ? null : (AssetStructureField)o;
        }
        set { ViewState["StructureField"] = value; }
    }

    public abstract T DataField { get; set; }
}

Answer 1

Forget about abstract. Seems to me that the .NET web control inheritance chain layers on functionality rather than forcing tons of implementation on the poor “end product” controls. I’d see if I can go with the flow on this. And this implies inheriting from the appropriate class to get the base upon which to build (pun intended).

Looks like you want to build composite web controls. Read carefully the documentation on System.Web.UI namespace. Consider inheriting from System.Web.UI.CompositeControl. It gives you a child control collection and some built-in rendering. And it implements INamingContainer for managing child control unique IDs.

Just a thought, maybe you can make a class that constructs custom composites at runtime (can you say factory pattern?). Read carefully the documentation on System.Web.UI namespace Anyway, the base already knows how to render the composite. Each sub-control (textbox, listbox, etc) knows how to render itself. In the factory, each sub-control is given it’s data binding. Then injects them into your custom CompositeControl constructor(s).