Override INamingContainer

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

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.

-Brock
DevelopMentor
http://staff.develop.com/ballen

> 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 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.


"Brock Allen" <> wrote in message
news: .com...
> 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.
>
> -Brock
> DevelopMentor
> http://staff.develop.com/ballen
>
> > 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

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.

-Brock
DevelopMentor
http://staff.develop.com/ballen

> 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.
>
> "Brock Allen" <> wrote in message
> news: .com...
>
>> 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.
>>
>> -Brock
>> DevelopMentor
>> http://staff.develop.com/ballen
>>> 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

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...

"Brock Allen" <> wrote in message
news: .com...
> 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.
>
> -Brock
> DevelopMentor
> http://staff.develop.com/ballen
>
>> 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.
>>
>> "Brock Allen" <> wrote in message
>> news: .com...
>>
>>> 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.
>>>
>>> -Brock
>>> DevelopMentor
>>> http://staff.develop.com/ballen
>>>> 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

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.

-Brock
DevelopMentor
http://staff.develop.com/ballen

> 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...
>
> "Brock Allen" <> wrote in message
> news: .com...
>
>> 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.
>>
>> -Brock
>> DevelopMentor
>> http://staff.develop.com/ballen
>>> 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.
>>>
>>> "Brock Allen" <> wrote in message
>>> news: .com...
>>>
>>>> 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.
>>>>
>>>> -Brock
>>>> DevelopMentor
>>>> http://staff.develop.com/ballen
>>>>> 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