March 6, 2021
Hot Topics:

VB.NET Uncovered: Working the Web

  • By Karl Moore
  • Send Email »
  • More Articles »

Before we dive into the nuts and bolts of Web Forms, let's fill up the ol' pipe and sit around talking theory for a mo.

Now, what's so wrong with the Web development tools we have right now?

Well, for any serious development, you're really going to have to head for ASP. And I have to admit - I just don't like it.

For a start, the code can get messy. You're mixing the presentation layer (the actual HTML) with your ASP code. It's like putting all your code behind forms. Sure, there are ways to get around it - but it's still messy.

Next up, you have to mess around supporting all those users with old computers that never bother to upgrade their Web browser (damn them). If their browser doesn't, say, support JavaScript, you need to detect that and change your page to suit.

There's state management too. Someone logs in and you want to remember his or her preferences - so you try twiddling with the Session object. And then your site grows and you own a Web Farm - suddenly, multiple machines need access to the Session object. And you get stressed. And it gets messy.

Quite miraculously, VB.NET solves all of these problems with Web Forms.

Now, Web Forms are a part of the newly-rechristened ASP.NET (no longer ASP+). They're effectively interactive Web pages you create inside VB.NET. And it's all very easy.

You simply create a "Web Form" in VB.NET. This process is similar to designing a WebClass - and unfortunately, the interface is just about as advanced which means you're probably better off designing a fancy page in FrontPage, then pasting the HTML over to your VB.NET Web Form.

Top Tip: In that last paragraph, I said you could write code in FrontPage, then paste it over to your VB.NET Web Form. Slight lie, that. When I tried, it seemed to accept very simple pages - but as soon as the form layout got a little complex, it bunked. This should fix itself in later versions.

So, you've designed your skeletal page, the Web Form. You can then add the interactive elements in VB.NET - such as a regular text box or submit button. You can also add 'Web Controls', which are more advanced HTML features that aren't like ActiveX controls and don't require a separate download. They also work with any browser - we'll be looking at this in more detail later today.

Top Tip: VB.NET bundles with a bunch of Web Controls - the Calendar control being the most impressive. We'll meet this one later today.

After designing the page and adding the elements, you tap out a little code to make it all work together. So, let's say you have a text box and a button on your Web Form. You might add code behind the button to take the value behind your text box and display it in a label. Or add it to a database. Or verify it against a list of users, then redirect him/her to the members area. Or whatever.

The core message here however is that you can treat the entire page and objects on it as objects. You're not thinking about 'requesting' certain form fields, as you would in the old ASP world. Here, you just refer to the objects as you would a regular Windows Form - and you've done it!

As we're comparing the old ASP to the groovier ASP.NET, let's review the problems I mentioned above and see how they're solved.

First off, the HTML getting mixed with ASP code. You don't have that in VB.NET - the HTML page is completely separate from the code. There's only one line right at the top of your Web Form that refers to the code module. The Web server does the rest.

Top Tip: Just as old ASP files had a .ASP extension, Web Forms have a .ASPX extension. When the Web Server serves up this file, it is processed by the .NET Framework first - and 'Web Controls' are converted into HTML, your code is compiled and so on - all automatically for you. We'll look at this more later.

Next up, with the old ASP, you'd mess around checking the users browser and altering the content you send depending upon its capabilities. With VB.NET, it's all handled for you - the .NET Framework only spews out HTML that can be understood by the target browser. No problemo.

And what about state management? Ohh, this is a touchy subject for most ASP programmers. Bane of their lives, they'll tell you. Well, in ASP.NET, state is encoded and stored in the page sent back to the user (it's essentially a hidden field). The next time that page is submitted, the data can be read and used as and when.

Top Tip: You can think of state management in ASP.NET as similar to using Property Bags. It will automatically add certain things to the Property Bag - such as text box values - plus you can add bits yourself, then refer back to them later. If you want to get all technical, you'd say that the state information is "tokenized"

Another Top Tip: Tests have shown there to be a performance advantage in using this method of state management over the old ASP Session object.

Yet Another Top Tip: Security is still an issue here - the data is apparently encoded to a high standard, however if you need real security during a particular operation, you may need to use this state management alongside existing database passwords records and all that jazz. Depends on what you're looking for.

Well, that's ASP.NET for you. It's new, it's groovy, it's what the ASP world has been begging for. And if you're a Visual Basic programmer looking to get your foot in the Web world, this is the ideal opportunity.

So... as some singing chick once said, let's get physical.

Page 2 of 5

This article was originally published on October 22, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date