I know with ASP.Net 4.0 you can have ClientIDMode to static to have clean ID.
Is there something to have "name" the same way?
Example :
<input type="text" name="_wizard$ctl00$CaptionName" id="captionName">
You could output a key/pair javascript collection with the list of controls you're looking to operate on client-side. Control.ClientID and ClientScript.RegisterStartupScript are your friends.
Related
Should I use ASP elements with a runat="server" attribute or an HTML form?
It seems like using ASP tags such as <asp:TextBox> is much more comfortable since I don't have to redirect the user to another page on a form submition, but also from what I've seen, it seemed like HTML forms are the more accepted way. I was starting to wonder if using ASP elements increases server load or has any other disadvantage?
In case I should use ASP elements, how do I validate the input with Javascript before sending it to the server?
In case I should use HTML forms, how do I not redirect the user on submition and also not run the server code on page load?
You can easily use the HTML5 input type in Web Forms by adding the runat="server" attribute, so that it can be accessed on the server-side:
<label for="name">Name:</label>
<input type="text" id="name" name="name" required
minlength="4" maxlength="8" size="10" runat="server">
Note, on the server-side you will access it via the Value property of the input element, not with the Text property of a typical ASP.NET textbox control.
Contrary to what a lot of people think, ViewState only ever becomes a problem when people do silly things like nesting data-bound controls, in which case it can become bloated very quickly.
Not sure what you're asking regarding validation... but you still have options like this on both client and server. If you're working with an existing Web Forms project, I would stick with regular ASP.NET controls and keep it simple. This way, you can have out-of-the-box validation on both client and server.
I know I can eliminate ID mangling in ASP.NET 4.0, but can I also eliminate name mangling? This looks like the best I can do:
<input name="ctl00$body$txtName" type="text" id="txtName" />
Is that correct?
ASP.NET relies on name mangling to route posted form data to input controls in nested naming containers. The ways to avoid name mangling are:
Don't use nested naming containers such as master pages or user controls. Input controls that are placed directly on an .aspx page will have simple names.
Don't use the standard ASP.NET input controls. Instead, you could:
Put <input type="text" name="name" /> (without runat="server") in the .ascx/.aspx and access its value via Request.Form["name"].
Create a custom server control that does the same.
Ok, so here's the deal. I needed to change the values of form elements dynamically (server side), I need to keep the MasterPage, and I have panels on the page as well. There is no way around it.
What I have done instead, is use server side "yellow tags", and public variables:
HTML:
<input type='hidden' name='x_login' id='x_login' value="<%= x_login %>" />
Code:
Public x_login As String = "some value"
And to access the value after a postback:
Request.Form("x_login")
Thanks to Michael Liu's answer for the very last bit there. I've upvoted his answer just for that reason.
Given a textbox:
<asp:Textbox runat="server" id="txtAddress1" />
This renders as something similar to:
<input name="ctl00$mainContent$txtAddress1" type="text" id="ctl00_mainContent_txtAddress1" />
I don't think browsers autocomplete features recognise this name/ID as a field they can autofill, they are not standard recognised names.
Is there any way to overide the client ID's so that autocomplete has a better chance of recognising them?
2 Points with this.
1) The "Override the Name" feature was introduced in ASP.Net 4.0, where for any property you can choose a hardcoded name instead of the dynamic name. You need to be careful on this as you don't want 2 objects sharing a name.
2) ASP.Net 2.0 and above (may have been in v1.0) has a property on the control called "AutoCompleteType" which provides a hint to the browser on what sort of information is required in the box.
Assuming you're using Asp.net 4.0, and you're aware of the points mentioned by DJIDave, you can use the ClientIDMode property on a control, and set it to 'Static'. Then, what ever you specify in the Id field in Asp.Net will be brought through to your final markup, and will not be 'mangled' (for want of a better word) by Asp.Net.
As I understand it, the <input type=email> element in HTML5 will render as a simple text field in browsers that do not support the tag. On other browsers it will render properly, like on the iPhone it will bring up the e-mail keyboard layout.
I’d like to use this in a project but my input fields are <asp:TextBox> controls. How can I use the HTML5 element but still access its data server-side like the rest of my fields?
There is an update for .NET framework 4 which allows you to specify the type attribute
http://support.microsoft.com/kb/2468871.
See feature 3 way down the page
Feature 3
New syntax lets you define a
TextBox control that is HTML5
compatible. For example, the following
code defines a TextBox control that is
HTML5 compatible:
<asp:TextBox runat="server" type="some-HTML5-type" />
you can try adding the attributes manually, like:
TextBox1.Attributes["type"] = "email";
TextBox1.Attributes["type"] = "url";
TextBox1.Attributes["type"] = "number";
Sorry I'm a bit late to the party, though I think that others can benefit from what I did. I have a page which is HTML 5 though we still have .NET 3.5. We wanted to keep the .NET element, though have the type change to email. I've tried several methods (including Milox above) to no avail, though the one which worked for me was the following: I added a JavaScript property to the element itself inline (when I put it in a script tag it wouldn't pick up for some reason...)
Here is what your tag would look like if you use my changes:
<asp:TextBox runat="server" type="email" onfocus="this.type='email'"/>
Eli
Whether or not it is accessible as a server control, you should be able to access the HttpRequest.Form collection and retrieve the value. No matter what the browser does with the tag, it has to submit a string to the server.
in your .aspx file add
<input type="text" required autofocus placeholder="Email Address"
class="txt-input txt-input-username" ID="myTextBox" runat="server"/>
in your Code Behind .cs
myTextBox.Attributes["type"] = "email";
This Worked For Me
You need to create your own custom control and override the Render routines. Feel free to use either the source code or DLLs
Is it possible to set a specific ID on an ASP.NET server control? Everytime I assign an ID and run the web form the ID changes.
For Example:
<asp:TextBox ID="txtName" runat="server"></asp:TextBox>
Gets translated into this:
<input id="ct100_ContentPlaceHolder1_txtName" type="text" />
I think this is do to me using master pages, but if so how can I be sure a control will have a certain ID(for javascript purposes). I placed the auto-generated id in my javascript and it is working, but I would prefer to have used the id's that I originally assigned them. Is this possible?
(This is for version:ASP.NET 3.5)
Starting with .NET 4 you have greater control about how the client-side IDs look like (see this post for details).
To force a specific client-side ID, you have to set the ClientIDMode to static. The following will render an <input> element with id="txtName":
<asp:TextBox ID="txtName" ClientIDMode="static" runat="server"></asp:TextBox>
Although if you do this, you have to ensure that you don't have two controls with identical client-side IDs. Check the article linked above for other options.
This is the way web controls ID's are in .NET prior to version 4.0. Version 4.0 introduces client IDs, which you can read about here.
You can use somthing like this in your JS:
var something = '<%= txtName.ClientID %>';
You can use the Control.ClientID property in your codebehind to get the actual id after it's been added to the control tree.
Super annoying choice made by the asp.net webforms people.