Override INamingContainer

[PJ]

Is there a way to prevent the INamingContainer behaviour that prefixes the
id of server controls in master pages with the format [master page
id]_[content id]_. I would prefer to manage the potential id attribute
conflicts myself, rather than having such verbose id attributes throughout
my site.

Thanks,
~PJ

 

[Brock Allen]

The problem is that you don't know what some other control will emit for
an ID. I imagine what your problem is is that you want to hard code the ID
in your javascript to a well known value. Instead of hard coding, the approach
is to dynamically emit your javascript with the proper ID using the Control.ClientID
property.

 

[PJ]

The id is known, one can set the id on the master page, content place holder
controls, etc. The pattern is always the same. I know what the final
rendered id value will be and can set the proper css/javascript selectors
properly ahead of time.

My problem is simply not having total control of the rendered id attributes
and the verbosity of the rendered values.

The problem is that you don't know what some other control will emit for
an ID. I imagine what your problem is is that you want to hard code the ID
in your javascript to a well known value. Instead of hard coding, the approach
is to dynamically emit your javascript with the proper ID using the Control.ClientID

property.



Is there a way to prevent the INamingContainer behaviour that prefixes
the id of server controls in master pages with the format [master page
id]_[content id]_. I would prefer to manage the potential id
attribute conflicts myself, rather than having such verbose id
attributes throughout my site.

Thanks,
~PJ

 

[Brock Allen]

Sure, of course you can make it work. I think what I was trying to say is
that the pattern is what's documented to potentially change in the future,
thus the preference to use the ClientID property and merge that dynamically
into your javascript.

The id is known, one can set the id on the master page, content place
holder controls, etc. The pattern is always the same. I know what
the final rendered id value will be and can set the proper
css/javascript selectors properly ahead of time.

My problem is simply not having total control of the rendered id
attributes and the verbosity of the rendered values.

The problem is that you don't know what some other control will emit
for an ID. I imagine what your problem is is that you want to hard
code the ID in your javascript to a well known value. Instead of hard
coding, the
approach

is to dynamically emit your javascript with the proper ID using the
Control.ClientID

property.


Is there a way to prevent the INamingContainer behaviour that
prefixes the id of server controls in master pages with the format
[master page id]_[content id]_. I would prefer to manage the
potential id attribute conflicts myself, rather than having such
verbose id attributes throughout my site.

Thanks,
~PJ

 

[PJ]

You're seriously are recommending dynamically generating .js files based on
the prospect that the next version of asp.net might change their rendering
of id attributes?

Insane man...

Sure, of course you can make it work. I think what I was trying to say is
that the pattern is what's documented to potentially change in the future,
thus the preference to use the ClientID property and merge that
dynamically into your javascript.

The id is known, one can set the id on the master page, content place
holder controls, etc. The pattern is always the same. I know what
the final rendered id value will be and can set the proper
css/javascript selectors properly ahead of time.

My problem is simply not having total control of the rendered id
attributes and the verbosity of the rendered values.

The problem is that you don't know what some other control will emit
for an ID. I imagine what your problem is is that you want to hard
code the ID in your javascript to a well known value. Instead of hard
coding, the
approach

is to dynamically emit your javascript with the proper ID using the
Control.ClientID

property.


Is there a way to prevent the INamingContainer behaviour that
prefixes the id of server controls in master pages with the format
[master page id]_[content id]_. I would prefer to manage the
potential id attribute conflicts myself, rather than having such
verbose id attributes throughout my site.

Thanks,
~PJ

 

[Brock Allen]

Not insane; I'm simply suggesting the documented way for identifying the
ID of controls in the client. This was the documented was of doing things
in ASP.NET v1.0 and if one had followed those guildlines originally then
one's code would work going forward in v1.1 and v2.0.

You're seriously are recommending dynamically generating .js files
based on the prospect that the next version of asp.net might change
their rendering of id attributes?

Insane man...

Sure, of course you can make it work. I think what I was trying to
say is that the pattern is what's documented to potentially change in
the future, thus the preference to use the ClientID property and
merge that dynamically into your javascript.

The id is known, one can set the id on the master page, content
place holder controls, etc. The pattern is always the same. I know
what the final rendered id value will be and can set the proper
css/javascript selectors properly ahead of time.

My problem is simply not having total control of the rendered id
attributes and the verbosity of the rendered values.


The problem is that you don't know what some other control will
emit for an ID. I imagine what your problem is is that you want to
hard code the ID in your javascript to a well known value. Instead
of hard coding, the

approach

is to dynamically emit your javascript with the proper ID using the

Control.ClientID

property.


Is there a way to prevent the INamingContainer behaviour that
prefixes the id of server controls in master pages with the format
[master page id]_[content id]_. I would prefer to manage the
potential id attribute conflicts myself, rather than having such
verbose id attributes throughout my site.

Thanks,
~PJ