How is ASP+ Different from ASP?

Having seen in outline how ASP+ is now an integral part of the operating system, we need to look at the other aspect. How, and why, is ASP+ different to earlier version of ASP? And just how different is it? Well, if you just want to run existing pages and applications, you probably won't notice the differences much at all. However, once you open up the ASP+ SDK or Help files, you'll see a whole new vista of stuff that doesn't look the least bit familiar.

 

Don't panic! We'll work through the main differences next. We'll start with a look at why Microsoft has decided that we need a new version of ASP, and how it will help you, as a developer, to meet the needs of the future when creating Web sites and applications. We'll follow this with a checklist of the major new features of ASP+, then examine each one in a little more detail. The remainder of the book then covers the new features one by one, explaining how you can use them.

 

 

 

 

 

 

 

 

 

 

 

 

 

Why Do We Need a New Version of ASP?

In the Introduction to this book, we listed the main motivations that Microsoft had when designing and developing ASP+. After all, considering that ASP has been so successful, why do we need a new version? There are really four main issues to consider:

 

q         Currently, ASP can only be scripted using the basic non-typed languages such as VBScript and JScript (unless you install a separate language interpreter). While ASP does parse and cache the code for the page the first time it is executed, the limitations prevent more strongly-typed languages like Visual Basic and C++ from being used where this would be an advantage. ASP+ provides a true language-neutral execution framework for Web applications to use.

q         It is also very easy to create huge ASP pages containing a spaghetti-like mixture of code, HTML, text, object declarations, etc. And it's hard to re-use code, unless you place it in separate 'include' files – not the best solution. In many environments, developing a Web application utilizes the skills of a wide range of professionals, for example, you have programmers writing the code, and designers making the HMTL look good. Having both the code and the content intermixed in a single file that both of these groups need to operate on makes it difficult for them to work together. ASP+ allows true separation of code and content.

q         In previous versions of ASP, you have to write code to do almost anything. Want to maintain state in form fields? Write code. Want to validate data entered on the client? Write code. Want to emit some simple data values? Write code. Want to cache regions of pages to optimize performance? Write code. ASP+ introduces a real component model, with server-based controls and an event driven execution paradigm similar in concept to the way that a Visual Basic 'Form' works now. The new ASP+ server controls are declarative (i.e. you only have to declare them in order to get them to do something), and so you actually write less code – in fact, in many situations you don't have to write any code at all!

q         The world out there is changing. The proportion of users on the Web that will access your site through an 'Internet device' such as a mobile cellular phone, personal digital assistant (PDA), TV set-top box, games console, or whatever else, will soon be greater that the number using a PC and a traditional Web browser. This means that we probably have to be prepared to do more work at the server to tailor our pages to suit a specific device. We'll also have to create the output in a whole new range of formats such as the Wireless Markup Language (WML). And, in addition to creating WML for rendering, new Internet devices and business applications are going to want to be able to send and receive XML data from Web applications. Doing this today from ASP requires you to manually use an XML parser, convert data to and from XML schemas, etc. ASP+ Web Services makes it much easier.

 

Besides all of this, the rapidly changing nature of distributed applications requires faster development, more componentization and re-usability, easier deployment, and wider platform support. New standards such as the Simple Object Access Protocol (SOAP), and new commercial requirements such as business-to-business (B2B) data interchange, require new techniques to be used to generate output and communicate with other systems. Web applications and Web sites also need to provide a more robust and scalable service, which ASP+ provides through proactive monitoring and automatic restarting of applications when failures, memory leaks, etc. are discovered.

 

So, to attempt to meet all these needs, ASP has been totally revamped from the ground up into a whole new programming environment. While there are few tools available to work with it just yet, Visual Studio 7.0 will be providing full support to make building ASP+ applications easy (both ASP+ Pages and ASP+ Services).

 

The rich, component based, event driven programming model is specifically designed to be 'tools friendly', and this support will be available for all Visual Studio languages – including VB, C++, and C#. And you can be sure that third party tool manufacturers will not be far behind.

The Big Advantages with ASP+

The biggest challenges facing the Web developer today must be the continued issues of browser compatibility, and the increasing complexity of the pages that they have to create. Trying to build more interactive pages that use the latest features of each browser, whilst still making sure that the pages will work on all the popular browsers, is a nightmare that refuses to go away.

 

And, of course, it will only get worse with the new types of Internet device that are on the way, or here already. In particular, trying to build pages to offer the same user-level capability to cellular phones as to traditional browser clients is just about impossible. The text-only 12-character by 3-line display of many cellular phones does tend to limit creativity and user interaction.

 

One obvious solution is to create output that is targeted at each specific client dynamically – or create multiple versions of the same site, one for each type of client. The second option is not attractive, and most developers would prefer the first one. However, this implies that every hit from every user will require some server-side processing to figure out what output to create.

 

If this is the case, why not automate much of the process? To this end, ASP+ introduces the concept of server controls that encapsulate common tasks and provide a clean programming model. They also help to manage the targeting of all the different types of client.

Server-side HTML Controls – Less Code to Write

ASP has always provided the opportunity to execute components on the server, and these components can generate sections of the page that is returned to the user. ASP+ extends this concept through server controls. All that's required to turn any HTML element into a server control is the addition of an extra attribute: runat="server".

 

Any HTML element in a page can be marked this way, and ASP+ will then process the element on the server and can generate output that suits this specific client. And, as a by-product, we can do extra tricks – in particular with HTML <form> and the associated form control elements, where we can create the code to manage state during round trips to the server. This makes the programming experience less monotonous and dramatically more productive.

 

While the concept of having HTML elements that execute on the server may at first seem a little strange, as you'll see it adds a whole new layer of functionality to the pages, and makes them easier to write at the same time. What more could a programmer want?

The Problems with Maintaining State

One of the most cumbersome tasks when creating interactive Web sites and applications is managing the values passed to the server from HTML form controls, and maintaining the values in these controls between page requests. So one of the core aims of ASP+ is to simplify this programming task. This involves no extra effort on the part of the programmer, and works fine on all browsers that support basic HTML and above.

 

Take a look at the following section of code. This creates a simple form using HTML controls where the user can enter the name of a computer and select an operating system. OK, so this isn't a terribly exciting example in itself, but it illustrates a pretty common scenario used by almost every web application out there today. When the form page is submitted to the server, the values the user selected are extracted from the Request.Form collection and displayed with the Response.Write method. The important parts of the page are highlighted in the code listing:

 

This screenshot shows what it looks like in Internet Explorer 5. When the user clicks the Submit button to send the values to the server, the page is reloaded showing the selected values. Of course, in a real application, some the values would probably be stored in a database, or be used to perform some application-specific processing – for this example we're just displaying them in the page:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

One problem is that the page does not maintain its state, in other words the controls return to their default values. The user has to re-enter them to use the form again. You can see this is the next screenshot:

 

To get round this situation, we have to add extra ASP code to the page to insert the values into the controls when the page is reloaded. For the text box, this is just a matter of setting the value attribute with some inline ASP code, using the HTMLEncode method to ensure that any non-legal HTML characters are properly encoded. However, for the <select> list, we have to do some work to figure out which value was selected, and add the selected attribute to that particular <option> element. The changes required are highlighted below: