Bypassing INamingContainer for server controls on page

[TS]

The clientID of our controls have become very long since we have 2 master
pages that our pages inherit from. Some team members at work are thinking
they want to override ClientID for our controls (custom controls inherited
from normal .net controls) so when the controls are rendered, the id we
specify for the control also is the clientID. This will minimize the size of
the response to the client.

I have tried to think of all the implications of this, but can only think of
it affecting scenarios where there are templated controls, mainly when doing
ITemTemplates and specifying controls in it, such as in grid editing.

If we were using a 3rd party control and it specified a control with a
similar id as one of ours, this control would most likely implement
INamingContainer and thus there would be no conflict with our control I
don't think.

If we never plan on doing in-grid editing, can anyone think of any other
things that the proposed solution would hurt us later?

thanks

 

[bruce barker]

asp.nets calling the controls loadpostback data event depends on the
rendered control id matching. another option is to make the masters id
short (can be set in the masters oninit).

-- buce (sqlwork.com)

 

[TS]

right, they have gotten them to match so the only scenario is whether or not
we will be susceptable to other problems in the future since unique naming
would be nullified.

what ways could break this code in the future?

thanks Bruce!

 

[Steven Cheng[MSFT]]

Hi TS,

I agree with Bruce. The reasonable and safe approach is try reducing the
naming for the master page or any parent container as much as possible. For
the ClientID, the built-in default implemention is derived it from all the
super level NamingContainers. This is quite important when the server
control is nested in any other parent control container or template
container(such as those template databound control you've mentioned). And
for such scenario, the hierarchical naming rule will help the ASP.NET
runtime to associate the client-side postback element to the server-side
control. Therefore, I would surely recommend not to override it (remove the
hierarchical naming format).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi TS,

Just want to check whether you still have any questions on this issue, if
so, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Steven, you said:
"...the hierarchical naming rule will help the ASP.NET
runtime to associate the client-side postback element..."

we have proved that the plain clientID without the parent container's id
prefixed does run correctly and identified correctly.
1. Are you thinking that it might not be possible or that it is less
efficient without the hierarchical searching?
2. Like i've said it all works without the containers' prefix, so i still
need some more compelling reasons why not to do it.

thanks