Microsoft Web Form

Web Forms is a DotNet terminology for web thin client applications developed using MicrosoftDotNet platform.

AspDotNet is the environment for development of Web Forms. It has been successful in the market place due to good performance and a better development environment, compared to the old AspApplication way of mixing presentation with business logic.

Web Forms have the potential to change Web programming by introducing a new programming model built around server-side controls�a model in which controls render their own UIs by generating HTML to return to clients and firing events that are handled by server-side scripts. Since all the action takes place on the Web server, virtually any browser can run a Web Forms app. And thanks to Visual Studio.NET, building a Web Forms app is a lot like using Visual Basic: just drop a control onto a form then write an event handler.

The framework does this by storing hidden information on the form rather than store the state on the server. I see two drawbacks to this approach. The first is security, the second is the difficulty in "going off on a tangent", such as a search screen or yes/no question and then redisplay the form. The state should be stored on the server, not the client-side form IMO. (Some once said that there was a way to do this in the product, but I have not verified that yet.)

ASP.NET supports server-side sessions. You can store your data server-side in the session object or in the form's "view state". There is no significant difference between what ASP.NET does with regard to state and any other web UI development framework.

Can you go to a different form and then come back to finish one? I don't have a test machine yet.

[ASP.NET handles "server-side" code by saving the page state, posting the page back to the server, executing, and returning the new page. The cleverness is in the illusion of server-side programming, not in the implementation. I find the abstraction to be leaky and inefficent, and that the framework gets in the way of attempts to improve it. The fancy "web controls" included are crappy DHTML/postback implementations. There's some benefit there, mainly in the convenient packaging, but it's not going to "change Web Programming" any time soon cause it's the same old crap. I've been writing server-side event handlers (better than ASP.NETs silly postbacks, too...) for years, although without the explicit support from the framework.]

You would think MS would push rich-client technology that was their specialty pre-web. VisualBasic and their C++ GUI tools were the king of the kill, so why kill the concept and replace it with half-ass web frameworks? Fancy GUI's might give them a (temporary) edge over the competition. I think they got overly obsessed with chasing Java rather than play to their market strengths. Java turned out not to be a significant GUI threat, leaving the niche open. (see WhatIsWrongWithTheGeneralVisualBasicApproach)

WpFe. Wait for it ...

A note on the more technical side: Building web forms in AspDotNet 1.0, using Visual Studio, involves two levels of inheritance from Page. The "code behind" form is the first descendant. An "anonymous" descendant of that is generated and built, after deployment, by untouchable Microsoft code, from the ASPX format. It's troublesome at times. (And after all that fuss about inheritance, the web forms designer won't correctly handle a code behind file that doesn't inherit directly from Page.)

AspDotNet 2.0 uses partial classes instead of the second level of inheritance. --JesseMillikan

CategoryDotNet, CategoryWebDesign