«

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" <> wrote
in message
news:...
> 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

Hi TS,

I assume you're referring to this post:
http://msdn.microsoft.com/newsgroups...icrosoft.publi
c.dotnet.framework.aspnet&mid=3055846c-93b8-46b7-b8b7-9d5b2642b2c6&p=1

Steven is not in office these days, so I will work with you on this. Sorry
for the delay since your reply in the previous post somehow didn't show up
in our tool.

I've carefully reviewed the post and I totally agree with Bruce and Steven.
INamingContainer is designed to make the IDs unique on the whole page, and
the IDs will be the cornerstone of how ASP.NET engine uses them to
correctly handle states or route events.

However, I agree that your suggestion is reasonable, it's just currently
ASP.NET is not designed to let you override the ClientID.

http://connect.microsoft.com/VisualS...k.aspx?Feedbac
kID=103081

Hope this helps.


Regards,
Walter Wang (, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

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

thanks

are there any other scenarios or types of controls like templated controls,
where the unique ID based on hierarchy would need to be in place without
naming collisions or other bad behaviour?

thanks

"Walter Wang [MSFT]" <> wrote in message
news:...
> Hi TS,
>
> I assume you're referring to this post:
>
http://msdn.microsoft.com/newsgroups...icrosoft.publi
> c.dotnet.framework.aspnet&mid=3055846c-93b8-46b7-b8b7-9d5b2642b2c6&p=1
>
> Steven is not in office these days, so I will work with you on this. Sorry
> for the delay since your reply in the previous post somehow didn't show up
> in our tool.
>
> I've carefully reviewed the post and I totally agree with Bruce and
Steven.
> INamingContainer is designed to make the IDs unique on the whole page, and
> the IDs will be the cornerstone of how ASP.NET engine uses them to
> correctly handle states or route events.
>
> However, I agree that your suggestion is reasonable, it's just currently
> ASP.NET is not designed to let you override the ClientID.
>
>
http://connect.microsoft.com/VisualS...k.aspx?Feedbac
> kID=103081
>
> Hope this helps.
>
>
> Regards,
> Walter Wang (, remove 'online.')
> Microsoft Online Community Support
>
> ==================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>

Hi TS,

Thanks for your reply. However, I'm not sure if I fully understand your
question. It's not the template control that has this special behavior,
it's all that the interface INamingContainer matters. It's only a marker
interface (an empty interface); when ASP.NET engine generates the
ClientID/UniqueID, it will use the interface and ID property to determine
them. Currently it's better to let ASP.NET generate them and use them, if
you do change them, some built-in function may or may not work since it's
really not designed to be changed by user code.

Regards,
Walter Wang (, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

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

Hi TS,

I'm writing to check the status of this post. Please feel free to let me
know if there's anything unclear. Thanks.


Regards,
Walter Wang (, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

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