Steven, i lost this message conversation from outlook express and made a
post online (see last one on this page). Please answer it as it hasn't been
yet.

thanks

                 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

                         Was this post helpful to you?
                  Reply |    Top

     bruce barker 7/3/2007 8:00 AM PST

                   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 wrote:
                 > 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
                 >
                 >

                         Was this post helpful to you?
                  Reply |    Top

     TS 7/3/2007 10:42 AM PST

                   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!

                 "bruce barker" <nospam@nospam.com> wrote
in message
                 news:e5P4xJYvHHA.736@TK2MSFTNGP06.phx.gbl...
                 > 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 wrote:
                 > > 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
                 > >
                 > >

                         Was this post helpful to you?
                  Reply |    Top

     Steven Cheng[MSFT] 7/3/2007 10:22 PM PST

                   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.

                         Was this post helpful to you?
                  Reply |    Top

     Steven Cheng[MSFT] 7/8/2007 6:54 PM PST

                   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.

                         Was this post helpful to you?
                  Reply |    Top

     TS 7/20/2007 1:31 PM PST

                   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

                 "Steven Cheng[MSFT]" wrote:

                 > 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