What is the porper way to get user input in ASP.NET? - asp.net

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.

Related

asp.net: Handling form data in Visual Studio 2010

Climbing the learning curve for creating asp.net webform pages with Visual Studio 2010 (VB).
I had written a fairly complicated .aspx page with form controls, including textboxes and buttons, etc. I never thought to place the form controls inside a <form> block. Instead, all the controls include the "runat" directive; for example, <asp:textbox id="txtUserName" runat="server"> etc. In the codebehind I access the data with strUserName = txtUserName.text. This seems to work just fine.
Now, though, I received some form pages from our contracted "professional" web developer wherein the form code is all enclosed in a <form runat="server">block, and none of the controls include the runat directive. Accessing the data from these controls is a little different: It uses the <input type="text name="txtUserName" id="txtUserName" /> method, and accessing the data in the codebehind
is strUserName = Request.Form("txtUserName").ToString.
My method seems to work fine, but I am wondering if there is a difference in behavior or reliability between my method and his. Even though my way works, am I doing it wrong?
Mine is based on online research I have done to learn this stuff, and I don't remember seeing anything that looked like his. However, just today I see places that are saying that on .aspx pages, form controls MUST be enclosed in a <form> block (i.e., this page at w3schools.com).
Can anyone clarify this for me?
Thanks for your help!
You're not doing it incorrectly (you're using my preferred approach) but your inputs should still be in an enclosing Form tag.
He's using HtmlControls (System.Web.UI.HtmlControls namespace) and you're using web controls (System.Web.UI.WebControls.) Your controls provide better functionality on the server (viewstate and accessing via server code) and his approach is lighter weight.

When working in Visual Studio, can the ' asp: ' portion of an element be omitted?

Situation: I have been creating webpages in HTML5/CSS3 & Javascript using Sublime 2 text editor for a year, however a college course now requires me to use Asp.Net and Visual Studio 2010. I do not use the designer because I am proficient at doing things by hand, however I find that writing asp: inside every element is time consuming and causes syntax errors when applied to some HTML 5 tags and not others.
Example HTML 5: <button id="btn" type="submit" value="Button"/>
Example Asp.net: <asp:Button ID="Button1" runat="server" Text="Button" />
Question: Can the asp: portion be omitted without effecting anything or is it required for IIS or the C# back-end functionality? What about runat="server" can that be omitted?
Google has come up dry regarding my inquiry, so any help is appreciated.
you simply cannot remove either of the two
but hear me out why, because I have a feeling you are not familiar with ASP and therefor are mistaking the meaning of the asp: and the runat="server" syntax.
first: runat="server"
this property on an element, tells the the compiler that this is actually a server side control
so a <button/> is not the same as an <button runat="server"/>
the first one is pure html, while the second one is a control, which can be bound to on the server side. .Net will give it a clientID (not to be mistaken by the ID you have to give it yourself).
second: asp:
this is a prefix, on certain elements, that tells the compiler these are ASP controls (the default controls given by the ASP.net framework). These include Buttons, TextBoxes, DropDownLists, ...
do not mistake 1 of these with a html element.
an <asp:Button id="myAspButton" runat="server"/>
is not the same as a <button id="myHtmlButton"/>
the first, is a server side control, which can be bound to (see it's runat="server" attribute), and this control renders to the browser as a <input type="submit"/> for example.
you could alter the rendering of the asp.net button class to make it return something entirely differnt if you wish.
and you are also not limited to using asp.net classes.
you can create your own controls, and put them in a custom created library
you could give those your own prefix.
if I created such a custom control, I could register a prefix for it in the web.config file,
and thus I could create a custom button extending from the original one (but with a default label in front...
<myc:CustomButton ID="myButton" Text="myButton" Label="myLabel" runat="server"/>
which could render into:
<label>myLabel</label>
<button ID="*******">myButton</button>
the asterisks are symbolizing the Unique ID it will get from the .net framework
if you want to know more on custom controls, or extending default controls
here is a step by step explanation to create custom controls, or extend from a TextBox control.
it also shows how you add a custom prefix for your controls (in the this case 'cc')
you can find more info here
The runat="server" part is required to tell .NET that it will have to render a button there (which will contain .NET specific ID for processing upon POST). Not too familiar with web forms (I started with MVC), but I would assume that the asp: part is to help distinguish between server controls and standard HTML markup.
Why not try removing it and if it breaks something, then you know it's needed. For instance if the button doesn't show up after removing it, then obviously the .NET markup parser needs it to be there in order to know that it is a place holder for a server control.

How can I use HTML5 email input type with server-side .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

Handling elements generated by Javascript in Asp.Net

I have several elements in my web page generated by JavaScript.
Here's an example of such content:
<input id="uploadfile01" type="file" onchange="change(1);" />
<input id="uploadfile02" type="file" onchange="change(2);" />
My question is:
How can I interact with these elements in the server side, (Asp.net) after a post?
(Since the elements were dynamically generated they do not exist in the original asp.net page)
I dont think that would be possible.....if i am not mistaken you want to give the option to attach multiple files. i think it would be better to place a set number of fileupload controls and set there display to none and you can use javascript to show them.
i know that this is not what you are looking for but after a postback the controls will be lost and even if they are added again they will lose there contents.(had you been generating them through code behind)

When to use HtmlControls vs WebControls

I like HtmlControls because there is no HTML magic going on... the asp source looks similar to what the client sees.
I can't argue with the utility of GridView, Repeater, CheckBoxLists, etc, so I use them when I need that functionality.
Also, it looks weird to have code that mixes and matches:
<asp:Button id='btnOK' runat='server' Text='OK' />
<input id='btnCancel' runat='server' type='button' value='Cancel' />
(The above case in the event you wanted to bind a server-side event listener to OK but Cancel just runs a javascript that hides the current div)
Is there some definitive style guide out there? Should HtmlControls just be avoided?
It might be useful to think of HTML controls as an option when you want more control over the mark up that ends up getting emitted by your page. More control in the sense that you want EVERY browser to see exactly the same markup.
If you create System.Web.UI.HtmlControls like:
<input id='btnCancel' runat='server' type='button' value='Cancel' />
Then you know what kind of code is going to be emitted. Even though most of the time:
<asp:Button id='btnCancel' runat='server' Text='Cancel' />
will end up being the same markup. The same markup is not always emitted for all WebControls. Many WebControls have built in adaptive rendering that will render different HTML based on the browser user agent. As an example a DataGrid will look quite different in a mobile browser than it will in a desktop browser.
Using WebControls as opposed to HtmlControls also lets you take advantage of ASP.NET v2.0 ControlAdapters which I believe only works with WebControls, this will allow you programatic config driven control over the markup that gets emitted.
This might seem more valuable when you consider that certain mobile browsers or WebTVs are going to want WML or completely different sets of markups.
In my experience, there's very little difference. As Darren said, if you don't need server-side functionality, HTML controls are probably lower-impact.
And don't forget, you can bolt server-side functionality onto almost any HTML control just by adding a runat="server" directive and an ID to it.
well... i wouldn't use an html control if you don't need to do anything on it on the server. i would do
<input id='btnCancel' type='button' value='Cancel' />
fin.
By adding runat="server" you can get access to any HTML controls in server side..
and I believe HTML controls are less weight compared to ASP.NET server controls..

Resources