Tech Off Thread

5 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

how to control IDs of server-side controls in ASP.NET

Back to Forum: Tech Off
  • User profile image
    Ion Todirel

    i mean if i don't want ASP.NET to rename my server control HtmlSelect "Select2" to "UserControl1_Select2" when rendering, how to do that? instead i would want to provide a custom naming solution

  • User profile image
    footballism

       I don't think you can do it, ASP.NET's naming solution can ensure the uniqueness of the html tag when rendered eventually in the browser, how could you ensure that your own naming solution will not confuse the ASP.NET framework?

    Sheva

  • User profile image
    stevo_

    This is by design of how the INamingContainer works, if a control at some point implements INamingContainer, its childrens ids are appended by the containers name.

    INamingContainer is just a flag interface, and doesn't require you to implement anything in your class, it only acts as a flag to the composition so that it knows the given control should act as a container for its children, one of the effects of this is that child controls of a container are prefixed with the containers id, and a containers id can be prefixed by ITS containers id.

    Thus meaning you can have some really fantastic client side ids such as:

    ctl00_ctl00_ctl00_ctl00_ctl00_ctl00_ctl00_ctl00_ctl00

    I believe the id is determined by System.Web.UI.Control which pretty much everything control based in asp.net will inherit from.

    So unless you want to write your own Control base (implementing: IComponent, IDisposable, IParserAccessor, IUrlResolutionService, IDataBindingsAccessor, IControlBuilderAccessor, IControlDesignerAccessor, IExpressionsAccessor)- and recreate the entire asp.net control library in the .net framework to extend from your own implementation of Control- you will struggle.

    However, if your writing a composite control where you don't want your Control to act as a container, I'd suggest not implementing INamingContainer.

  • User profile image
    mtutty

    Can someone explain to me, then, how we're supposed to make sense out of FORM values that are POST-ed to anywhere other than the originating page? This is something that makes no sense to me.

    In the case where every interaction with a rendered page goes BACK to that page, then populating the control values is a moderate time-saver. But as soon as you step outside this model, everything goes to hell.

    Look at what the Castle project has to do in order to get away from posting back to the originating page. I've taken some of that code as well, so that Commands acting on data can be separated from the Views that show the data.

    Page Controller is well and good. But it is a common MS failing that tools work AGAINST you when you step outside their expected usage (see also MS Project Web from non-domain PCs)

  • User profile image
    W3bbo

    mtutty wrote:
    Can someone explain to me, then, how we're supposed to make sense out of FORM values that are POST-ed to anywhere other than the originating page? This is something that makes no sense to me.


    Use HtmlControls, not WebControls, and override the Render method, that's all you need to do.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.