Published: Saturday, July 15, 2000
ASP.NET: An Introduction and My Views on the Matter, Part 2
Read Part 1
In Part 1 I started my introduction of ASP.NET, explaining that ASP.NET provides
both enhancements and fundmental changes to ASP. In this part I'll continue discussing these differences!
Post-Back Forms: Many ASP developers use the ol' post-back form trick when building ASP pages
that need to acquire some user-information and process it. For those unfamiliar with the lingo or technique,
a post-back form is a Web page form (created using the <FORM ...> tag)
whose ACTION property is set not present or set to the same URL of the Web page that displays the
form. When the user then submits the form, the same ASP page is reloaded, but with the user's inputs passed
back to the form. To handle these in ASP, lengthy if statements are needed to determine whether
or not the post-back has occurred or not.
With ASP.NET, these if statement headaches are a thing of the past. Now developers can create an
ASP.NET page with a server control button (we'll get to server controls in a bit). In the ASP.NET code, the developer
can create a function that is executed when the button is clicked (well kind of, we'll look into this in more detail
later in the article). This is accomplished using clever programming from Microsoft and post-back forms!
This way, all of the actions following a form submittal can be located within a single function, rather
than in a series of hard-to-read if statements.
Server Controls: With ASP, all methods of collecting user input were accomplished through the
default HTML controls using forms. For example, creating a text box into which a user could enter information
might be created with a simple few lines of code:
<FORM>
<INPUT TYPE=TEXT NAME=MyTextBox>
</FORM>
|
With ASP.NET, these are replaced by server controls. These server controls can be created in an
ASP.NET page with a few simple lines of code. For example, to create a text box in an ASP.NET page, you could
use the standard HTML tags as shown above, or use a server control with the following code:
<FORM ACTION="blah.aspx" METHOD=POST RUNAT="server">
<asp:textbox id="MyTextBox" runat="server"/>
</FORM>
|
This server control text box, created with the asp:textbox tag, instructs ASP.NET that you
need a text box. This server control cleverly creates the needed HTML to render a standard text box.
So, when a user visits the ASP.NET page, the HTML returned reads:
<FORM name="ctrl2" method="post" action="intro7.aspx" id="ctrl2">
<INPUT type="hidden" name="__VIEWSTATE" value="a0z-426043723...">
<input name="MyTextBox" type="text" id="MyTextBox">
...
|
Note that the server control text box is rendered into normal HTML. Also note that HIDDEN
form value __VIEWSTATE. This form variable passes along the state of the form, based upon user-input.
This article will not attempt to delve into the details of how server controls work or how they maintain
state. All that is important to understand now is that server controls return plain, valid, HTML to the
client... therefore, as before with ASP, any standard Web browser can view ASP.NET pages just fine, since just HTML
is being sent to the client!
Deployment is a Breeze!: The ASP.NET team at Microsoft obviously understood how difficult ASP applications
can be to deploy. For example, if you create a large ASP application with many custom COM components on your development
servers, moving this application to your production servers can be a headache. Ensuring that all of the COM objects
exist on both servers and that these components are registered can be one of the biggest pains when deploying
an ASP application. Also, keeping identical IIS's settings on both the development and production servers can
be annoying as well.
ASP.NET eases both of these pains. Most notably, with ASP.NET COM registration is no longer an issue! I'm not kidding!
Simply copy the COM DLL you need to the appropriate DLL directory... that's it! No regsvr32
needed! ASP.NET also provides a configuration file (in text format) that can be modified to alter various settings
that use to be only modifiable through IIS's administration pages. These two wonderful enhancements make deploying
ASP.NET applications a breeze!
Read Part 3
Read Part 1