So I posted the updated wwHoverPanel control yesterday and while it addressed some of the core issues, it still isn't working in all situations due to the naming issues of the ASP.NET containership naming schemes. Well, ASP.NET is doing nothing unpredictable really, but my goal for the control was that it should be easy to reference and access from within script code.

So when the control is hosted in a MasterPage and you're doing a JSON page callback I don't want the user to have to use a cryptic name like:

ctl100_Content_LookupPanel.Helloworld('Rick',Helloworld_Callback);

or

document.getElementById('ctl100_Content_LookupPanel');

To do this the user either needs to type the ugly name above or:

<%= LookupPanel.ClientID %>.Helloworld('Rick',Helloworld_Callback);

So anywhere the panel is referenced then would require code like this which is – well, ugly as shit. It also makes the control handling a lot more difficult, because in some cases the control would have to generate the base ID (LookupPanel) or in other cases generate the ClientID into the code.

To end user the experience is confusing.

Given that this is a 'worker' control, not something that will be stuck into containers and iterated over it seems much more reasonable to use simple names directly:

LookupPanel.Helloworld('Rick',Helloworld_Callback);

and

document.getElementById('LookupPanel');

So, today I realized an obvious solution which is to simply override ClientID and UniqueID in the control class:

/// <summary>

/// Override to force simple IDs all around

/// </summary>

public override string UniqueID

{

    get

    {

        return this.ID;

    }

}

/// <summary>

/// Override to force simple IDs all around

/// </summary>

public override string ClientID

{

    get

    {

        return this.ID;

    }

}

This complete overrides the extended naming functionality that ASP.NET provides and results in the control names being rendered into the output as a simple ID names that don’t reflect the control hierarchy.

So now the code automatically generates the simple ID all the time both for client and server side code and users can talk to this control with its simple name in script code.

For this particular control which essentially isn't bound to the control tree hierarchy this is just fine. The control either fills the panel with data from an AJAX callback and displays it inplace or moved up to the mouse cursor, or it acts essentially as non-visual control – when allowing JSON Pagecallbacks.

Now, there's a caveat of course: Due to this overriding the page author now has to ensure that the name of the control is unique on the page. Since this control is likely to be only dropped once maybe twice (once for panel operation and once for callback operation) this is not really problem, but it is unconventional. I can live with that.

Can anybody see where this would cause problems beyond possible naming conflicts?