Fighting to move away from the recursive Page.FindControl

Question

I developed a web control panel that has a structure of controls embedded inside the controls. In many scenarios, I have a control identifier and should work on the actual control. Thus, I use the utility method - a recursive implementation of FindControl, which searches for the page (or any other provided object, but I always use the page) for the identifier of the control.

/// <summary> /// Page.FindControl is not recursive by default. /// </summary> /// <param name="root"> Page </param> /// <param name="id"> ID of control looking for. </param> /// <returns> The control if found, else null. </returns> public static Control FindControlRecursive(Control root, string id) { if (int.Equals(root.ID, id)) { return root; } foreach (Control control in root.Controls) { Control foundControl = FindControlRecursive(control, id); if (!object.Equals(foundControl,null)) { return foundControl; } } return null; } 

This feature has the ability to become quite slow. I understand how slow I entered log4net into it. Now I'm trying to move away from him where I can, but I'm not sure what other options I have, if any.

For example, a user drags a control onto my web page. The event handler is as follows:

 protected void RadListBox_Dropped(object sender, RadListBoxDroppedEventArgs e) { //e.HtmlElementID is the UniqueID of the control I want to work upon. RadDockZone activeControlDockZone = Utilities.FindControlRecursive(Page, e.HtmlElementID) as RadDockZone; } 

There is no guarantee that this control will be a direct child of the page, and I cannot (as far as I know!) Have the ability to determine where in my controls this identifier can be, except by searching from page down.

The only thing I can think of is to save the lookup table of each object on the page, but this seems like a wrong idea.

Has anyone else experienced this issue?

Answer 1

Hrm, how about this ... The HtmlElementID should be the client identifier of the control, which we hope will be the fully qualified location of the control.

Something like that:

Page_Parent_0_Control_1

You can break the identifier string, and then go from the page to the corresponding control, collecting the path to it.

Page findcontrol Page_Parent (indexC # 0) Page_Parent_0 findcontrol Page_Parent_0_Control (indexC # 1)

Still not the best way, but that would save you from finding a shotgun for the control in question.

Hope this works for you, or at least gives you another way to look at the problem :)