Controlling Web Pages on the Server Side

Developing for the Web using .Net and C# can be quite revealing. This becomes very evident when we start examining even the most petty, routine tasks. For instance, it is often necessary to conditionally display a section of a Web page. There are a variety of reasons why you would want to do this; for instance, based on a user's role, certain parts of a page could become unavailable. Or consider a search function, where the search options only become available once you click on a link. By examining how this is implemented in .NET, we get to see the power of server-side abstraction for a page in the .NET Web world.

Before leading you into the nitty-gritty of the code, let me first explain the approach of solving this problem, and then I will explain each code segment that is involved.

To develop for .NET on the Web you can use either server-side Web controls (called webforms) or HTML controls. Much of the .NET philosophy for Web development is focused on server-side controls. The proposed solution makes use of webform server-side controls.

There is a server-side webform control called a "Panel." A Panel is a rectangular area on your HTML page, the visibility of which can be controlled on the server side. So you start out by putting the HTML segment inside of a panel. This HTML segment can be made up of both server-side and client-side controls. The idea is that once you set the panel visibility to "false," the entire HTML segment will disappear from view. Secondly, you make use of another webforms control called "LinkButton," which is essentially a hyperlink, but can be made to behave like a button via the OnClick server-side method. Inside of this method, you simply access the C# representation of the Panel object and set its visibility to true or false. The page will automatically paint itself in response.

One important difference when programming in .NET for the Web is that every control on your page is represented as a .NET object on the server side. Moreover, the state of these objects (or controls) is maintained between multiple round trips to the server. This allows you to respond to events either on the client or on the server side. While responding to events on the server side, rest assured that when the page is repainted, all of its internals will repaint as if nothing had happened. You don't need to refill any controls; this is done automatically. This freedom, aided by the IDE for making object access transparent, becomes quite an envious paradigm to work in. The most attractive point is that a good OO programmer can work in one programming language model. The use of JavaScript is minimal to none. Debugging is streamlined. The only minor drawback I have seen in the model is that you won't be able to use HTML editors like FrontPage or Dreamweaver for prototyping your Web sites. Once that hurdle is deemed reasonable, the server-side programming model seems to be quite remarkable. There are implications for scalability, etc., but I won't discuss those topics here.

Inside the Code

Here are the steps:

Get a panel for your HTML section.

Place your HTML inside of the panel.

Create a LinkButton.

Provide an onClick function.

Hide/unhide the panel inside of the button click function.

1. Get a panel for your HTML section.

Open up your design view of your page (.aspx) and choose the "Webforms Controls" toolbox. From the toolbox, drag a panel control onto your design view of the HTML page. You will see a rectangular box. Size it until it is big enough to include your intended HTML segment.

3. Create a LinkButton.

This section needs a bit of explanation. Why am I using a LinkButton instead of a hyperlink? The implication of a hyperlink is that you are free to go to any Web page, including the current one. But there is no implication that I want to return to the same page while altering parts of that page. In addition, there is no server-side, convenient method like OnClick available with a hyperlink.

The LinkButton control offers the look and feel of a hyperlink, but with two other benefits, namely:

5. Hide/unhide the panel inside of the OnClick function.

This piece of code is very illustrative of the server-side programming model that knows how to maintain its state. When a user clicks on the link, the above code is executed. But the programmer has made no changes to any other part of the HTML page. The controls themselves know how to repaint their own data. It is this convenience that makes this programming so consistent.

Conclusion

Here are some very interesting features I was able to cull so far from the .NET model.

Server-side programming model.

State of a Web form is automatically maintained between invocations.

Highly consistent unified object model both for GUI and the back end.

Extremely helpful IDE prompts every method and every possible parameter.

The prompting also extends to writing the XML inside of the HTML view of the Web page.

A unified web.config for configuration needs.

Although this example is a fairly simple one that could have been accomplished with simple if constructs in a traditional Web world, this server-side model illustrates the more interesting promises of NET, namely: "A consistent unified server-side programming model that maintains its state."