A Fast Track Guide to ASP.NET - Chapter 1

Server Processing

If you've done some Visual Basic programming, then you'll find the switch to the new ASP.NET Server Controls fairly painless, but they might cause some initial confusion if your programming has been limited to ASP. There's no need to worry though, as they are extremely easy to understand and use -- it's just that they are very different from ASP.

One of the big problems with ASP is that pages simply define one big function, which started at the top of the page and finished at the bottom. The page content is rendered in the page order, whether it is straight HTML or ASP-generated HTML. Therefore, our logic was dependent upon its position in the page, and there's no way to target HTML controls except by rendering them as part of the stream. Anything we do requires us to write code, and that includes the output of HTML elements.

ASP.NET solves this problem by introducing a declarative, server-based model for controls. This is where the concept may seem alien to ASP programmers, because the controls are declared on the server, can be programmed against on the server, but can be event driven from the client. This sounds pretty weird, but it's simple to use. All we have to do to turn a normal HTML control into a server control is add runat="server" as an attribute. For example:

<input id="FirstName" type="text" runat="server">

This is a standard HTML control, but the addition of the runat attribute allows the control to be programmed against with server-side code. For example, if this control is placed within a form and we submit the form back to the same page, we can do this in our server-side code:

Dim PersonFirstName As String      
     
PersonFirstName = FirstName.Text

Making a control run on the server allows us to use the ID attribute to identify it directly. This allows the code to become more readable, since we don't have to refer to the form contents or copy the contents into variables. It's also more natural to refer to the control directly, which makes developing pages simpler. If you've done any Visual Basic or VBA programming then this won't seem too alien for you.

If you've only ever done scripting in ASP, then this may seem strange, but that's only because it's a different way of working with content to and from the browser. You've probably done database access, so you've used objects, called methods, and set properties, and the ASP.NET Server Controls aren't really any different from this.

The new server processing architecture is covered in Chapter 4.

Web Form Controls

Converting existing HTML controls to server-side ones is simple, but there are still several problems with this approach:

• Consistency. We are still stuck with the rather non-intuitive nature of some HTML controls. Why for example, is there an INPUT tag for single line text entry, but a TEXTAREA tag for multi-line text entry? Surely a single control where we specify the rows and columns makes more sense?
• User Experience. How do we easily write sites that render rich content for browsers such as IE, while also preserving compatibility with down level browsers? HTML doesn't have the ability to change its content depending on the browser -- we have to write the code for that.
• Devices. How do we write sites that cope with devices other than browsers? WAP-Phones, PDAs, and even fridges have browsers nowadays. Like the browser issue, we'd have to manually write code for this.

To alleviate these problems Microsoft has created a set of server controls, identified by the asp: prefix. The ASP.NET server controls tackle the above problems by:

• Providing a consistent naming standard. For example, all text entry fields are handled by the TextBox control. For the different modes (multi-line, password, etc.) we just specify attributes.
• Providing consistent properties. All server controls use a consistent set of properties, making it easier to remember. For example, the Text field of a TextBox is more intuitive than a Value field.
• Providing a consistent event model. Traditional ASP pages often have large amounts of code handling the posting of data, especially when one page provides multiple commands. With ASP.NET we wire-up controls to event procedures, giving our server-side code more structure.
• Emitting pure HTML, or HTML plus client-side JavaScript. With one minor exception (which is intentional) the server controls emit HTML 3.2 by default, giving great cross-browser compatibility. This can be changed so that by default we target up-level browsers such as IE, where the controls will emit HTML 4.0 and DHTML, providing a richer interface. All the user ever sees is the HTML content, not the server controls.
• Emitting device specific code. Certain controls will emit HTML when requested by a browser, but WML when requested by a WAP phone. The control handles the detection of the device and the generation of the correct markup.

The controls will be covered in detail in later chapters, but let's take a quick look at a simple example to show how these controls work.