Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So I have been developing in ASP.NET WebForms for some time now but often get annoyed with all the overhead (like ViewState and all the JavaScript it generates), and the way WebForms takes over a lot of the HTML generation.

Sometimes I just want full control over the markup and produce efficient HTML of my own so I have been experimenting with what I like to call HtmlForms.

Essentially this is using ASP.NET WebForms but without the form runat="server" tag. Without this tag, ASP.NET does not seem to add anything to the page at all. From some basic tests it seems that it runs well and you still have the ability to use code-behind pages, and many ASP.NET controls such as repeaters.

Of course without the form runat="server" many controls won't work. A post at Enterprise Software Development lists the controls that do require the tag.

From that list you will see that all of the form elements like TextBoxes, DropDownLists, RadioButtons, etc cannot be used. Instead you use normal HTML form controls. But how do you access these HTML controls from the code behind?

Retrieving values on post back is easy, you just use Request.QueryString or Request.Form.

But passing data to the control could be a little messy. Do you use a ASP.NET Literal control in the value field or do you use <%= value %> in the markup page? I found it best to add runat="server" to my HTML controls and then you can access the control in your code-behind like this: ((HtmlInputText)txtName).Value = "blah";

Here's a example that shows what you can do with a textbox and drop down list:

Default.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="NoForm.Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head runat="server">
    <title></title>
</head>
<body>
    <form action="" method="post">
        <label for="txtName">Name:</label>
        <input id="txtName" name="txtName" runat="server" /><br />
        <label for="ddlState">State:</label>
        <select id="ddlState" name="ddlState" runat="server">
            <option value=""></option>
        </select><br />
        <input type="submit" value="Submit" />
    </form>
</body>
</html>

Default.aspx.cs

using System;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
namespace NoForm
{
    public partial class Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            //Default values
            string name = string.Empty;
            string state = string.Empty;
            if (Request.RequestType == "POST")
            {
                //If form submitted (post back)
                name = Request.Form["txtName"];
                state = Request.Form["ddlState"];
                //Server side form validation would go here
                //and actions to process form and redirect
            }
            ((HtmlInputText)txtName).Value = name;
            ((HtmlSelect)ddlState).Items.Add(new ListItem("ACT"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("NSW"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("NT"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("QLD"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("SA"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("TAS"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("VIC"));
            ((HtmlSelect)ddlState).Items.Add(new ListItem("WA"));
            if (((HtmlSelect)ddlState).Items.FindByValue(state) != null)
                ((HtmlSelect)ddlState).Value = state;
        }
    }
}

As you can see, you have similar functionality to ASP.NET server controls but more control over the final markup, and less overhead like ViewState and all the JavaScript ASP.NET adds.

Interestingly you can also use HttpPostedFile to handle file uploads using your own input type="file" control (and necessary form enctype="multipart/form-data").

So my question is can you see any problems with this method, and any thoughts on it's usefulness?

I have further details and tests on my blog.

share|improve this question
11  
There's this wonderful thing called MVC and Razor syntax. Check it out. –  jfrankcarr Sep 19 '12 at 1:37
    
Definitely found Razor to generate cleaner client side stufflez in my observations... –  Rig Sep 19 '12 at 1:59
3  
Does this code honestly look good to you? To me it looks like an ill-conceived knock-off of MVC, carelessly mixing HTML semantics with code-behind (not to mention an insane amount of casting) instead of just sticking to either the MVC paradigm of models and templating or the webforms paradigm of control trees. Not wanting to sound like a grumpy old fart here, but I just would not want to touch that code, ever. –  Aaronaught Sep 19 '12 at 2:05
2  
what you are doing is anti-pattern. For truly stateless and fast web-development you may simply consider asp.net/mvc - which will resolve all your challenges elegantly. In addition, MVC framework is open-source ! –  Yusubov Sep 19 '12 at 2:06
    
I don't see the advantage of this code. It looks like it will be very hard to maintain. It seems like your inexperience in this field has lead you to solve a problem that your not experienced enough to solve yourself. There is nothing wrong with Javascript there is a reason it is used. –  Ramhound Sep 19 '12 at 11:48
show 7 more comments

1 Answer

up vote 7 down vote accepted

The problems that I see:

  • Non-standard way of working: you are coming up with your own, fairly non-standard way of working. Any new developers you hire will have to learn the details of your framework. Some of them may not like it (e.g. see some of the comments above), and refuse to work in it. As you go along, you will also keep (re-)inventing lots of basic functionality, like data-binding, which is essentially a waste of your efforts.
  • Not using the technology's strengths: WebForms are an attempt to bring event-driven programming to the web. To enable this by default, a lot of state has to be passed around all the time. By working around this, you are losing most of the functionality and benefits of WebForms.
  • Existing technologies that do this already: There are excellent technologies that do what you are trying to do, but in a much better way. ASP.Net MVC is probably the best known. If you would like to develop in a style that is closer to the way the web actually works (and would like a framework which helps in that), try it. It really is an excellent technology, a bit of fresh air compared to WebForms.
share|improve this answer
    
You make some good points. –  John Sep 24 '12 at 5:22
    
@John thanks, and BTW, people have long been trying to get WebForms to be a bit more "light" in a similar way to yours. Most typically end up switching off ViewState (and managing it themselves, similar to you), or doing tricks like storing it on the server (session, file, DB, whatever - examples) so it doesn't get passed around. I've just found that the results aren't great for the amount of work you have to put in, compared with existing frameworks. –  Daniel B Sep 24 '12 at 10:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.