ASP.Net Forms
-
I do not believe that every ASP.Net web page requires a single full-page form. My ASP.Net experience is tragically (even comically!) limited, but wrapping the entire page in a form tag just sounds completely dumb to me and a weird way of setting up a system.
I am here either to be disabused of my naive notions, or to see my personal sanity and rationality vindicated. Now discuss, goddamnit.
-
If memory serves the reason they do it has to do with how view state is saved in a hidden field, though that would just be a reason for having a form tag not for wrapping the whole page in one.
-
@dhromed said:
I do not believe that every ASP.Net web page requires a single full-page form.
I do not believe this either. Similarly, I do not believe that every ASP.net web page should consist of 90% VIEWSTATE code.
@dhromed said:
My ASP.Net experience is tragically limited
Ditto, but common sense tells me that the HP packaging approach to a web page is flawed.
Experience also suggests that viewstate and asp.net in general can be abused by inexperienced coders passing themselves off as young dynamic whizzkids and gullibly accepted by old hats that know little else.
-
@locallunatic said:
If memory serves the reason they do it has to do with how view state is saved in a hidden field, though that would just be a reason for having a form tag not for wrapping the whole page in one.
ViewState is merely an artifact, albeit a very in-your-face one. The root cause is the WebForms concept as a whole: marrying WinForms to the web. The statefulness this concept requires is where all problems with WebForms stem from. Any one control on the page can '__doPostBack' and raise an event, which can be listened for by any other control in the page's control hierarchy, just like WinForms. You cannot make this concept work without some way to carry the entire state between client and server, including any input controls edited by the user. (ViewState only stores the last form state, not the newly edited state being sent to the server...)
Ironically, the one sane way to work with WebForms is to assemble a model or view model in the top Page instance, based on the Request.Forms or Request.Query collection, DataBind that (view) model to said Page instance and just rely on the trickle-down in DataBind to let it build up the entire page, ignoring any of the statefulness
At which point: Congratulations! You've managed to emulate most of what ASP.NET MVC formalizes.
(Interesting to know if you do take the databinding approach: in that particular case it is safe to have the
<form runat="server">tag immediately closed and to just place all real page content (including any form tags) after this closed 'god form' element. You should not simply omit the 'god form' altogether, or things will subtly break further down into the pipeline...)
-
I got pissed at a co-worker awhile back, who bitched at my app design because "the ViewState screws with CSS styles".
First of all, that's fucking gibberish. What does one have to do with the other?
Secondly, I had to explain that while I'm using ASP.net I am not using WebForms (the part he was bitching about).
A huge pet peeve of mine is people who don't even know what goddamned technologies they're using. If you don't know the difference between ASP.net and WebForms, ... first of all, how is that fucking possible? And secondly, please leave the industry post-haste. Because seriously. Also the people who bitch about JavaScript, then when you ask for details they only talk about DOM. JavaScript is not the same thing as DOM, morons! Grrrrrr!
In any case, assuming you are using ASP.net, and you are using WebForms, you're still only supposed to put the form tag around, you know, ACTUAL FORMS. It's retarded to make one that spans the entire page.
