Web Forms - Page 10

A part of ASP.NET, Web Forms are a forms engine. They provide a web browser-based user interface. A user interface can also be rendered with the updated version of Active Server Pages, but Web Forms represents the next generation of web interface development, including drag-and-drop development.

Divorcing layout from logic, Web Forms consist of two parts – a template, which contains HTML-based layout information for all user interface elements, and a component, which contains all logic to be hooked to the UI. It's as if a standard Visual Basic form were split into two parts: one containing information on controls and their properties and layout, and the other containing the code. Just as in Visual Basic, the code operated "behind" the controls, with events in the controls activating event routines in the code.

To make this new UI concept work, Web Forms have lots of built-in intelligence. Controls on Web Forms run on the server but make their presence known on the client. This takes lots of coordination and behind-the-scenes activity. However, the end result is web interfaces that can look and behave very much like Win32 interfaces today, and the ability to produce such interfaces with a drag-and-drop design tool. These web interfaces can also have the intelligence to deal with different browsers, optimizing their output for each particular browser. Supported browsers cover a broad range. At the top end are advanced modern versions like Internet Explorer 5.5, which support DHTML. At the other end are simpler, less capable browsers on hardware such as wireless palmtop devices. Web Forms will render themselves appropriately on all of these.

As with WinForms, Web Forms will be available to all languages. The component handling logic for a form can be coded in any language that supports .NET. This brings complete and flexible web interface capability to a wide variety of languages.

Server controls

Visual Basic developers are familiar with the idea of controls. They are the reusable user interface elements used to construct a form. The equivalent in a Web Form is called server-side controls.

Server-side controls essentially create a proxy on the server for a user interface element that is on a Web Form or Active Server Page. The server-side control communicates with local logic as necessary, and then intelligently renders its own UI as HTML as necessary in any pages that are sent out containing the control. It also handles its own HTML responses, and incorporates the returned data.

Server-side controls need significant intelligence to render HTML for different levels of browsers, and to coordinate events with the client on which the page is running. A wide variety of controls are expected to ship with Visual Studio.NET, bringing web-based interfaces much closer to Win32 interfaces. Third parties are expected to add even more options for server-side controls.

One of the most important and amazing features of server-side controls is that they manage their own state. In ASP.NET, it is no longer necessary to write a lot of tedious code to reload state information into HTML controls every time a page is refreshed. Web Forms handle state by sending a tokenised (compressed) version of the state information to the client browser each time a page is sent. The page then posts that state information back to the server when changing the page. The server controls grab this information, use or process it as necessary, and then send it out again with the next rendering of the page.

Console Applications

Though Microsoft doesn't emphasize the ability to write character-based applications, the .NET Framework does include an interface for such console apps. Batch processes, for example, can now have components integrated into them that are written to a console interface. (The part of the .NET Framework which implements the console interface is not shown in the .NET Framework diagram earlier in the chapter.)

As with WinForms and Web Forms, this console interface is available for applications written in any .NET language. Writing character based applications in previous versions of Visual Basic, for example, has always been a struggle because it was completely oriented around a GUI interface. Visual Basic.NET can be used for true console applications.

Program Interfaces

Web Services

Application development is moving into the next stage of decentralization. The oldest idea of an application is a piece of software that accesses basic operating system services, such as the file system and graphics system. Then we moved to applications, which used lots of base functionality from other, system-level applications, such as a database – this type of application added value by applying generic functionality to specific problems. The developer's job was to focus on adding business value, not on building the foundation.

Web Services represents the next step in this direction. In Web Services, software functionality becomes exposed as a service that doesn't care what the consumer of the service is (unless there are security considerations). Web Services allow developers to build applications by combining local and remote resources for an overall integrated and distributed solution.

In .NET, Web Services are implemented as part of ASP.NET,  (diagrammed at the top level of the .NET Framework), which handles all web interfaces. It allows programs to talk to each other directly over the web, using SOAP. This capability requires very little work on the part of the developer. All that is needed is to indicate that a member should be included in the Web Services interface, and the .NET Framework takes care of the rest. This has the capacity to dramatically change the architecture of web applications, allowing services running all over the web to be integrated into one application.

It is hard to over-emphasize the potential importance of Web Services. Consider, for example, the potential for Web Services to replace packaged software. A commercial software company could produce a Web Service that, for instance, calculates sales tax for every jurisdiction in the nation. A subscription to that web service could be sold to any company needing to calculate sales tax. The customer company then has no need to deploy the sales tax calculator because is it just called on the web. The company producing the sales tax calculator can dynamically update it to include new rates and rules for various jurisdictions, and their customers using the Web Service don't have to do anything to get these updates.

There are endless other possibilities. Stock tickers, weather information, current financial rates, shipping status, and a host of other types of information could be exposed as a Web Service, ready for integration into any application that needs it.

Chapter 8 contains a detailed discussion of Web Services.

The Next Layer – .NET Framework Base Classes - Page 9
Introducing .NET
XML as the .NET 'Meta-language' - Page 11