Dynamic Markup Property Collection for a WebControl

I wasn’t exactly sure how to write this title as it’s not easy to explain in a short sentence, however I can say that I am completely embarrassed by the result and may have to consider hiring a title consultant. However, for now it will have to do.

Ok so what is this about? Well let’s say you have the control from the last example and you don’t want a list of controls in the markup, but maybe you want a list of strings set in the markup. (Say for a list of settings) Or even better, let’s say you have controls already on the page but you want our ParentControl (Yes I said “our” but no I’m not proposing… yet) to do something with those controls. Say we want to have the ParentControl to assign some javascript to certain buttons on the page. Ok yeah, kind of dumb but that’s the example I made. I supposed you could think of it like this: You want a validation control to validate multiple controls but you want to give it the names of the controls in the markup. Anyways, let’s stick with the example I already have.

First off you’ll need to create a new class, something that you want to hold the information in. (Although truth be told I could do something way easier and just use a list of strings, but this should prove more interesting) Here’s the one I have:

  namespace Test.Frontend.ControlInControl
  {
    public class ChildControlDefinition
    {
        public String ControlName { get; set; }
    }
  }

Pretty sweet? Eh? Eh? No? Ok. So now we have a class, and that’s like wow. Now with the same attributes from the old example, build the WebControl:

    [ParseChildren(true)]
    [PersistChildren(false)]
    public partial class ParentControl : UserControl
    {
        public List<ChildControlDefinition> NamedControls { get; set; }
    }

Holy smokes, that just got way complicated compared to the last example. I added a whole new property NamedControls that is a list of the ChildControlDefinition class we created. Now you might notice that the AddedControls property from the old example isn’t there anymore. I just removed it to simplify this one.

And then there’s the markup:

    <asp:Button ID="mainButton" runat="server" />
    <uc1:ParentControl ID="ParentControl1" runat="server" >
        <NamedControls>
            <examples:ChildControlDefinition ControlName="mainButton" />
        </NamedControls>
    </uc1:ParentControl>

Now you might notice two things here:

1) There is a mark up section named “NamedControls” just like the collection. Can you guess why?

2) examples:ChildControlDefinition : This is the class type name and the TagPrefix for where the class is. For this to work, you have to register the assembly the class is in EVEN IF the class is in the web application assembly. So it would look like this:

<%@ Register Assembly="Test.Frontend" Namespace="Test.Frontend.ControlInControl" TagPrefix="examples" %>

Now what does this do for anyone? Possibly it prevents you from dying a little inside but it also allows you to find those controls within the usercontrol… Ah buh? Don’t worry, I’ll show you!

    [ParseChildren(true)]
    [PersistChildren(false)]
    public partial class ParentControl : UserControl
    {
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
            NamedControls.ForEach(ConnectButtonToClick);
        }

        private void ConnectButtonToClick(ChildControlDefinition control)
        {
            Button foundControl;

            foundControl = Page.FindControl(control.ControlName) as Button;

            if (foundControl != null)
            {
                foundControl.OnClientClick = "alert('clicked'); return false;";
            }
        }

        public List<ChildControlDefinition> NamedControls { get; set; }
    }

See what I did there? SOMETHING COMPLETELY USELESS and yes you too can now have that power. However, there might be something worth taking home from that example. From the list of ChildControlDefinition I was able to get the control name that I wanted to attach the worthless alert script to and attach it. How was that done? Well I just iterated through the ChildControlDefinition list, used the Page.FindControl method to find the control, and then set the OnClientClick method.

Now this example is pretty stupid but I hope you can see the overall value of this. One would be a paging controller that has a list of paging control names that it iterated through and sets various events so they can all work in harmony like one great big continuation of the Hands Across America utopia that just didn’t seem to make it.

Now to spin it Nintendo User Manual Style:

Think you are bad enough for Dynamic Controls? Take grab of the power within and dare to conquer! Take a chance, the world can be your for the taking! Dynamic is waiting…