T
TS
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" <[email protected]> wrote
in message
> 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
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" <[email protected]> wrote
in message
> 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