Html control and asp.net web control - asp.net

i would like to know what exactly the difference between Html control
and asp.net web control. why do we need these two types of controls?
i have placed one html input text ,html button and asp.net text box AND ASP.NET BUTTON on my web page
<input id="Text1" type="text" />
<input id="Button2" type="button" value="button" />
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" />
when i take view source, both are rendered similarly
<input id="Text1" type="text" />
<input id="Button2" type="button" value="button" />
<input name="TextBox1" type="text" id="TextBox1" />
<input type="submit" name="Button1" value="Button" id="Button1" />
what is the advantage of web control over html control.
I got some links in the internet,but not clear what exactly
they are used for.
http://www.extremeexperts.com/Net/FAQ/DiffBetweenServerandHTMLControls.aspx.
Could any one please explain the difference between these two controls.

First, if you drag an Html control from the Toolbox onto your design surface as in your example, the tag created does not include runat="server". That means it is native Html tag and not a .NET control. A native Html tag without the runat="server" has no server-side functionality. Thus, you could not set the value of the your "Text1" input tag in the code-behind.
Second, once you add the runat="server" to your Html input tag, you convert it from a native Html tag into a HtmlControl which derives from System.Web.UI.Control. Now the question could morph into the differences between something that derives from System.Web.UI.Control and System.Web.UI.WebControl. However, to specifically address your question, let's compare a standard input type="text" control to the TextBox control:
TextBox control can be access from the code-behind where an input control cannot (not easily) which also means that you can wireup server-side events for a TextBox control whereas you cannot with a standard Html control.
A TextBox control automatically saves its value using ViewState.
A TextBox control can be skinned using a Theme and .skin file whereas a native Html control cannot.
A TextBox can render as either an input type="text" control or a textarea depending on its TextMode property.
A TextBox control can participate in validation using validators.
Last but not least, the TextBox control can use control adapters to render differently in different browsers if required. See http://msdn.microsoft.com/en-us/magazine/cc163543.aspx.
Now, all that said, if you do not need any of WebControl capabilities, then using an native Html control is substantially leaner. In your example, you simply dragged two empty controls onto your design surface. If that is all you needed then using the .NET control would be overkill. However, as you start adding AutoComplete and server-side events and such, the full content, Javascript and all, of what gets to the Browser is much larger.

In short HTML controls don't persist their state while Postbacks. On the other hand ASP.Net control provides you to luxury to have their state saved while several Postbacks automatically. Different while using ASP.Net control instead of HTML element is:
<input type="hidden" name="__VIEWSTATE" value="dDwtNTI0ODU5MDE1Ozs+.................." />
This hidden field is auto generated by ASP.Net and it contains all you controls state in value attribute.

The server controls have a runat="server" attribute which enables you to provide server-side logic for these controls in the code-behind. You can also add this attribute to existing HTML controls to gain this same functionality.

The HTML controls are simple controls that correspond directly to HTML elements.
The ASP.NET Web Controls abstract the HTML elements, and generally provide more control over styling (though some would call this a bad thing).

Related

controlling how ASP.NET renders radio button lists in HTML

When I add ListItems to a RadioButtonList in code-behind, the labels are rendered after the input and placed inside a TD by ASP.NET.
<td>
<input type='radio' id='site123' name='groupname' value='123' />
<label for = 'site123'>this is a long label that wraps</label>
</td>
Is there a way to control how ASP.NET renders the markup, either selectively or globally? I'd like to have the input inside the label:
<label><input .... /> </label>
You can use a Control Adapter. They allow you to override the html rendering of any ASP.Net control. Aside from the link, I have a simple example in another question here:
Dropdownlist control with <optgroup>s for asp.net (webforms)?
Since you asked about doing this selectively, you would need to inherit a control from RadioButtonList, and then attach your control adapter to the inherited control, instead of RadioButtonList itself.

Control.UniqueID different after cross-page postback

I have a simple ASP.NET page with a MasterPage. Within the MasterPage, I have two login fields:
<input type="text" runat="server" id="txtUserName"/>
<input type="text" runat="server" id="txtPassword"/>
When the controls are rendered to the page, ASP.NET renders the following:
<input type="text" runat="server" id="ctl00_txtUserName" name="ctl00$txtUserName"/>
<input type="text" runat="server" id="ctl00_txtPassword" name="ctl00$txtPassword"/>
If I understand correctly, the name attribute corresponds to the UniqueID property of a control. However, when I'm debugging Page_Load and attempt to view the UniqueID of these fields, they have different values (ctl0$txtUserName and ctl0$txtPassword respectively)!
Note that this does not seem to be an issue on all pages using this MasterPage. Most of them work correctly and use ctl0$txtUserName and ctl0$txtPassword in both rendering and Page_Load.
Any idea what might cause ASP.NET to render a different UniqueID for a control than it uses in Page_Load?
I'm still not sure what was causing the generated UniqueIDs in the MasterPage to be different in Page_Load than when rendered to the page. However, I was able to get around the issue by storing the UniqueIDs of these fields in hidden fields. I was then able to access the values directly in the Request.Form collection.
In other words, I did this:
In the MasterPage -
<input type="text" runat="server" id="txtUserName"/>
<input type="text" runat="server" id="txtPassword"/>
<input type="hidden" id="txtUserNameUID" value="<%=txtUserName.UniqueID%>"/>
<input type="hidden" id="txtPasswordUID" value="<%=txtPassword.UniqueID%>"/>
During Page_Load of the child page -
string username = Request.Form[Request.Form["txtUserNameUID"]];
string password = Request.Form[Request.Form["txtPasswordUID"]];
Hope this helps anyone else struggling with UniqueID weirdness in ASP.NET!
Weird quirk I just became aware of: any wrapping controls that are runat server must also have IDs. For instance, if you have a panel around the control, i.e. whatever "ctl00" is, it must be assigned an ID. If it is not set, it will be allocated one and this can change.

ASP control vs HTML control

I'm new to web programming and I've started with ASP.NET 2.0. I would like to know what the differences are when using an HTML control rather than an ASP control, and I'd like to know too how the attribute runat="server" works.
These are the differences between asp.net controls and html controls
HTML server controls :
HTML server controls :are HTML tags understood by the server.
HTML elements in ASP.NET files are, by default, treated as text. To make these elements programmable, add a runat="server" attribute to the HTML element. This attribute indicates that the element should be treated as a server control. The id attribute is added to identify the server control. The id reference can be used to manipulate the server control at run time.
Note: All HTML server controls must be within a < form > tag with the
runat="server" attribute. The runat="server" attribute indicates that
the form should be processed on the server. It also indicates that the
enclosed controls can be accessed by server scripts.
Ex:
< input type="text" id="id1" runat="server" /> It will work.
HtmlTextControl class
< input type="button" id="id2" runat="sever" /> It will not work.
For html button control there is no compatiable version of control class.
corrected one is
< input type="submit" id="id2" runat="server" />
htmlButton class
< input type="reset" id="id2" runat="sever" /> This one will not work.
ASP.NET - Web Server Controls
Web server controls are special ASP.NET tags understood by the server.
Like HTML server controls, Web server controls are also created on the
server and they require a runat="server" attribute to work. However,
Web server controls do not necessarily map to any existing HTML
elements and they may represent more complex elements.
The syntax for creating a Web server control is:
< asp:textbox id="Textbox1" runat="server" />
These are also case insensitive. Here the important thing is to compulsory write runat="server". For HTML controls this is optional.
all HTML < input type="text" /> control's attributes are also available for these asp tagged server controls. Some special attributes are also there which we will discuss on Ajax for special attributes.
The biggest deference in my opinion is that ASP.NET controls are executed on the server, with the resultant HTML sent to the client and that ASP .NET Server Controls can detect the target browser's capabilities and render themselves accordingly.

Adding custom attributes to asp.NET RadioButton control

I want to add a custom attribute to an asp.net RadioButton called Key which I'm using client-side for an ajax request.
What I'm finding is that my aspx markup which is the following:
<asp:RadioButton ID="rdoPost" GroupName=PreferredContactMethod" value="Post" onclick="DoStuff(this)" runat="server" />
gets rendered in the page as
<span Key="ContactMethod">
<input id="rdoPost" type="radio" name="PreferredContactMethod"" value="Post" onclick="DoStuff(this);" />
</span>
whereas I'd expected (and hoped) to get the following
<input id="rdoPost" type="radio" Key="ContactMethod" name="PreferredContactMethod"" value="Post" onclick="DoStuff(this);" />
I've tried the same thing with an asp TextBox control and it works exactly as I'd expect simply adding the Key="myKey" attribute to the <input type="text"/> element.
Is there a way around this with the standard RadioButton control, or will I have to inherit from the standard one to achieve the markup I'm wanting?
Also... (sorry to ask two questions at the same time), is adding non-standard attributes to html markup a bad idea anyway? Currently I'm using these attributes in JavaScript in the following way:
var key = rdoPost.Key;
I've found from the question/answer below that the easiest way to do this is via the code-behind using the InputAttributes property as follows:
rdoPost.InputAttributes.Add("class", "myCheckBoxClass");
Why does ASP.Net RadioButton and CheckBox render inside a Span?

asp.net: difference between runat="server" and server controls

What is the difference in functionality between
<asp:Button id="button1" Text="Click me" runat="server" OnClick="submitEvent" />
and
<input type="button" id="button1" runat="server" value="Click me" />
Does the input with runat="server" attribute has other or limited properties and methods?
Thank you!
The first one creates a System.Web.UI.WebControls.Button while the second one creates a System.Web.UI.HtmlControls.HtmlInputButton.
Both are server controls, but the controls in the WebControls namespace generally has a bit more functionality than the controls in the HtmlControls namespace. Typically they put some data in ViewState to keep track of their state, and they have server side postback events.
Each controls in the HtmlControls namespace correspond exactly to an HTML element, while the controls in the WebControls namespace may be rendered differently depending on what the browser that is requesting the page can support.
The button represented by <asp:Button runat="server".../> will be converted to a web server control with a rich state model and different properties and methods which has more clear representation in real world like Button.Text = "Click Me".
The button represented by <input type="button" runat="server"..../> will be converted to html server control represented by HtmlInputButton; with has limited properties, methods and events. Most of the properties resemble the html equivalents like Button.Value="Click Me".
Note that elements in a markup page are pre-processed/compiled before being used and will be converted to a class representation where every element is represented by a control. You can access server side controls which are identified by the runat="server" tag from the code behind since they will have the correct matching server control(web/html), other static content including an <input type="button.../> tag with out the runat="server" will be represented as a LiteralControl.
The former line is ASP.NET, the latter simple XHTML.
The former gets parsed and interpreted on the server side, after which the HTML code is generated, which pretty much corresponds to your second example. The ASP.NET Button is really little more than light wrapper over th HTML input button functionality, and should be used wherever you need to handle the Click event on the server side (or in the general case any events), and is usually the way to go, since you're letting ASP.NET abstract the idea of a button on your page for you.
functionality of both the controls is same with the difference that first one is .net control and second one is html control that can be made servercontrol by using
runat="server".
and first one is rich in evants and metods thn the second one....
There is no server events associated with such a controls, but you can use it in codebehind to change it's properties.
Your second option won't probably even work. runat="server" will be rendered directly to the HTML output where it will have no functionality and will only break HTML validation.
input is an HTML element which has only HTML properties, and definitely no methods of any kind.

Resources