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.

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:

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.
–
AaronaughtSep 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 !
–
YusubovSep 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.
–
RamhoundSep 19 '12 at 11:48

1 Answer
1

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.

@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 BSep 24 '12 at 10:11