<asp:Textbox runat="server" Id="Username" />
This might ren开发者_StackOverflowder as:
<input type="text" id="ctl00_mainContent_Username" />
But in web.config if I do:
<pages clientIDMode="Static">
This renders as:
<input type="text" id="Username" />
I've gone for the second option, so client ID's are simpler and not dynamic, meaning I can have all my Javascript external because I don't need to use Username.ClientID
.
But why is it designed this way? Why does it give weird names to stuff? The second way just seems easier to work with.
It's decorating IDs so that there will never be duplicate IDs on a page even if you use that bit of server-side markup several times on one page.
Like most 'decorate this name automatically so that a duplicate can never occur' schemes, the name ends up long and ugly.
You have to remember that the original concept of ASP.NET was that nobody would ever look at the output HTML or care about details like IDs, because all that was abstracted away for you. So a simple, ugly, name decoration scheme would be fine - it was just an internal implementation detail.
The main reason behind ClientID is the user control. Consider having 2-3 text controls with same name in the 3 different user controls which are placed on same page.. How would you differ one from another....
The short answer
Because Asp.net puts whole page content inside a single FORM
element hence duplication can occur and using this technique it tries to avoid it (with success).
The long(er) one
When the whole page is inside a single FORM
we risk input name duplication (think of an editable list of entities that all have the same properties which would give them same names on inputs as well). Hence Asp.net names all controls based on their named container (INamingContainer
interface) and count. That's the easiest way to avoid any name conflicts.
When Asp.net 1.0 came out there wasn't any particular need for naming these controls differently, but lately with fat client applications there is (think of CSS styles per ID and client scripts).
It turns out though that a fairly static page won't change control's unpretty IDs either. It will be long, yes, but it won't really change during page life-cycle.
If you instead use static mode you will get the benefit of having nice(er) names, but risk their duplication which you should be aware of.
I'll just explain what I've understand.
For naming the element, ASP.net is naming the element according its hierarchy level, sor for your example, it is inde the page where the hierarchy is like this
MasterPage // MasterPage has <asp:ContentPlaceHolder ID="mainContent" runat="server" />
Page // textbox is inside the <asp:Content ID="Content1" ContentPlaceHolderId="mainContent" runat="server">
Where master page has the mainContent container control which the page resides. Since ASP.net is inside a single form, ASP.net is naming it that way for uniqueness of the element. ct100
is a prefix for control, and each control holding the control is concatenated hierarchically.
精彩评论