ASP+ Page Framework
ASP+ introduces a new page framework that provides an object model on the server for the contents of the page. This framework includes a new class of controls termed "server controls." Other new features include the addition of server-side comments (<%-- --%>) that allow you to comment out an entire block of code, data-binding expressions (<%# %>) that allow you to bind data to server controls, and new directives (<%@ %>) that allow you to declaratively set a number of page options.
Server controls are probably the most interesting new advance in the page framework. A server control is a control on the page that's instantiated on the server. Its namespace is merged with the page namespace so that you can manipulate it in code without having to alter the underlying HTML explicitly. This is hard to understand without an example. Here's the old way you would create a select list:
<SELECT NAME="Fruit">
<%
While Not rs.EOF
Response.write "<option>" & rs("Fruit").Value
Wend
%>
</SELECT>
As you can see, this approach requires you to place code between the select tags, which will render the option tags for the records in the database.
Here's one way to do this in ASP+:
<%
While Not rs.EOF
Fruit.Add(rs("Fruit").Value)
Wend
%>
<SELECT ID="Fruit" runat=server>
</SELECT>
This second way totally separates the code from the HTML, which it modifies. If you are familiar with the way VB populates listboxes this will look pretty familiar. Note the "runat=server" directive on the control. This is the syntax used to instantiate the control on the server side. ASP+ provides server-side implementations of all HTML-intrinsic controls and adds a number of additional controls. In all, ASP+ ships 45 built-in server-side controls. Vendors such as Software Artisans, VideoSoft, and others are working on additional controls.
Note that server-side controls are not ActiveX controls or design-time controls. They are constructs that exist only on the server and render themselves as standard HTML to the client. In this respect they are client-neutral, although several controls will render themselves in different ways depending on the client. An example of one of the new ASP+ controls would be the listbox:
<asp:listbox id="fruit" />
These controls use XML-like syntax and namespaces to define themselves. You may be asking yourself what server-side controls give you beyond a name space at runtime. Several features have been added to allow the use of controls without writing much code. First off, controls have a concept of view state. If you write a simple HTML form with no code, like this...
<html>
<body>
<form>
Name: <input type="text">
<input type=submit>
</form>
</body>
</html>
...what happens when you fill in your name and click the Submit button? The form is posted to the server, processed, and then returned to the client with the Name field blank. If you want to persist this value, you have to write code to make sure it's included in the field the next time it is displayed. ASP+ introduces a new concept called ViewState, which causes the contents of the control to be preserved across form submissions by making one modification to the form I showed above:
<html>
<body>
<form runat=server>
Name: <input type="text" runat=server>
<input type=submit runat=server>
</form>
</body>
</html>
If you are thinking that this is done with session state, you're wrong. If you look at the HTML this code renders to the browser, you'll find a hidden form field that ASP+ inserts automatically that contains the state information for all the controls in the form.
Server controls also raise events. Take the following form, for example:
<SCRIPT Language="C#" runat=server>
public void cmdNext_Click() {
Page.NavigateTo("page3.aspx")
Return;
}
public void cmdPrevious_Click() {
Page.NavigateTo("page1.aspx")
Return;
}
</SCRIPT>
<html>
<body>
<form runat=server>
Name: <input type="text" runat=server>
<asp:button id="cmdNext"
OnClick="cmdNext_Click" runat="server" />
<asp:button id="cmdPrevious"
OnClick="cmdPrevious_Click" runat="server" />
</form>
</body>
</HTML>
When the cmdNext button is clicked, the cmdNext_Click event is fired. Similarly, when the cmdPrevious button is clicked, the cmdPrevious_click event is fired. This means that the beginning of your form no longer has to be a large case or if/then/else statement attempting to determine which control the user interacted with. Instead, you can write event handlers and respond to the events raised by the page and the controls contained within it.
Server controls also allow you to separate the source above from the page easily. For instance, I could put the code behind the controls into a library by changing the script block to this:
<SCRIPT runat=server SRC="mycode.dll">
This statement will automatically wire all events dynamically to my code that resides in a compiled DLL. Visual Studio .NET takes advantage of this, in most cases, to separate the code from the HTML with which it interacts. I will cover server controls in quite a bit more depth in a future article.
ASP+ Web Services
Web Services are one of the coolest new features in Microsoft's .NET platform. A Web Service allows you to take an object and use HTTP to invoke it, rather than RPC. The advantages to this are clear. Instead of tightly coupling your objects with DCOM and relying upon RPC mechanisms to communicate, you can now use the common HTTP protocol and extend your services out to the Internet at large and take advantage of all the infrastructure support for load balancing, security, etc. that has been built into HTTP.
ASP+ provides a simplified model for creating Web Services. Instead of writing an .aspx file, you write an .asmx file, which contains a class with whatever methods the developer wishes to expose. ASP+ compiles the .asmx file on demand, generating the required SDL contract and creating a default page that documents the service and provides a facility for testing it. The Web Service can be consumed in multiple ways. It supports invocation via HTTP Get requests, HTTP Post requests, or HTTP Post requests with SOAP XML payloads. The developer requires no special knowledge of HTTP or XML. The Web Service infrastructure handles converting results into the appropriate XML format. In-depth discussion of this exciting feature is a topic for yet another article.
