I have a page that generates new text inputs, checkboxes, selects with JavaScript. So none of these controls has runat="server" set.
I would like to know if these controls are sent to the server on PostBack and become part of the Viewstate, altering it in any way.
The short answer is yes, by assignment.
Dynamically generated plain HTML elements in ASPX page will be treated as LiteralControl elements rather than WebControl elements, hence they don't affect ViewState directly like some ASP .NET server controls. However, since they're placed inside form tag (usually with runat="server" attribute), their values are posted together as postback event stage triggered by submitting the form, which identified as key-value pair in Request.Form collection (the key is recognized by name attribute of literal HTML element).
Suppose you have dynamically generated text box with JS like this:
<input name="FirstName" type="text" />
Then you can retrieve its value using Request.Form:
If Not String.IsNullOrEmpty(Request.Form("FirstName")) Then
Dim firstName As String = Request.Form("FirstName")
And, the important point, you can omit the string assignment above and assign literal text box value to ViewState:
ViewState("FirstName") = Request.Form("FirstName").ToString()
Note that only HTML server controls (e.g. <input runat="server" />) and ASP .NET server controls have control name directly accessible in code-behind and ViewState maintained automatically (unless having EnableViewState attribute set to false).
Additional ViewState reference:
Understanding ASP.NET View State
Related issues:
How to viewstate in normal HTML input in asp.net
Which controls have ViewState maintained?
viewstate for HTML control
Related
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.
According to MSDN and the MCTS self-paced training, asp.net can use Hidden fields for client-side state management. The book material goes on to say view-state is more secure than hidden fields because the data is encrypted.
I must be missing something here. I setup a Label and made it hidden. I can store data in this hidden label and it won't even be sent to the client browser. This not only works like server side state (note the runat=server), but this seems more secure than view-state because there's no need for encryption as the client can't even see the field.
<asp:Label ID="Label1" Visible="false" runat="server">secret info</asp:Label>
Contrast this with an HTML input field. Here, the client state info makes sense.
<input id="Text2" type="text" style="visibility:hidden;" value="secret 99" />
So what's the deal?
When you create a label in .net and set it's visibility to Hidden, it does not render to the client and its data is stored in viewstate.
Therefore, it is not "more" secure than viewstate as it is using viewstate to maintain the data.
Regarding hidden fields, there are four kinds: First up is the regular HTML one which is simply an input of type hidden. This has no visible rendering although it is in the html. It also has no viewstate properties. It is declared as:
<input id="MyId" type='hidden' value='whatever' />
The second one is a regular input with a css property marking it as hidden: If CSS is disabled or otherwise overriden then the control would be visible to the user. Other than that its pretty close to the same thing as a type='hidden'.
<input id='MyId' type='text' value='whatever' style='visibility:hidden' />
The third one is the .Net hidden field. This does has viewstate storage, but it also causes a regular hidden field to be generated in the html.
<asp:HiddenField id='MyId' runat='server' value='whatever' />
And, the fourth one is a regular .net text box that is marked as not-visible.
<asp:TextBox id='MyId' runat='server' Text='whatever' Visible='False' />
The .net ones will cause data to be placed in viewstate. The HTML ones do not. If you set Visible=False on a .Net control then it is not rendered to the client however it's data is typically stored in viewstate.
There are other ways of throwing data into the page, but they are derivations of the above.
Generally speaking if you have a value that your javascript code needs but you don't need to display it to the client then you use a hidden field (html or .net). If you have a secret value then typically you don't want this to go to the client side if at all possible. And that means even keeping it out of viewstate. As a side note, don't depend on viewstate "security' there are tools out there which will easily decrypt it.
A field which is not displayed is not a hidden field (even though it is "hidden").
Hidden fields are <input type="hidden" name="somename" value="somevalue" /> fields. And those can be manipulated by users.
How is a TextBox able to persist changes (e.g. text) even after the EnableViewState property is set to false in ASP.NET?
Because the ASP.NET Textbox control generates an HTML form input element <input type="text" name="x" />. You can verify this by looking at the source view from your browser on an ASP.NET page. When the form is posted, ASP.NET is able to read the text value from the HTTP POST contents. You can read more about it here and here.
I have an usercontrol with an attribute targetUrl. I add this user control to a page and write targetUrl attribute from this page like below:
<PBG:Modal ID="Modal1"
runat="server"
Height="180"
Width="500"
src="pop_adres_giris.aspx"/>
This worked properly, but I want to change the targetUrl attribute from javascript. And I can't do it. I write code like below, but it didn't work.
var frm = document.getElementById('Modal1');
frm.targetUrl = 'pop_adres_giris.aspx';
How can I do it?
The UserControl object, which generates HTML on the client side, are not accessible as the rich objects which are available when handling server side calls.
Depending what the UserControl is, you will need to use a different method to get it and set the "targetUrl".
In addition, to ease your accessing of elements within the DOM you may want to consider using a library such as jQuery or prototype
Once you have declared your control, for instance, if you were using an asp:Hyperlink control:
<div id="hyperlink_holder">
<asp:Hyperlink ... NavigateUrl="http://someurl" />
</div>
You know that asp:Hyperlink generates html like <a href="http://someurl" ... />
So we can access the element and change the link like:
$('#hyperlink_holder a').attr("href", "http://newurl");
In addition, note that the ID you give an item in ASP.NET is not necessarily the ID which will render in the id element in the HTML; it is instead a concatenation of a number of ids; therefore use selectors based on non runat="server" controls where possible, or pass the ClientID of the UserControl through to the client to use for selection if absolutely necessary.
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.