Creating Web Sites with ASP.NET Whidbey

Creating Web Sites with ASP.NET Whidbey

e remember clearly the time period before ASP.NET 1.0 shipped. While building applications using ASP, we said over and over “I sure wish we could use this stuff right now,” referring to ASP.NET. Having seen a preview version of ASP.NET Whidbey that’s included as part of the Whidbey release of Visual Studio .NET, we’re doing it again. We really want to use this new technology right now. Of course, the product is still in its early stages, so anything and everything can still change, but it certainly appears that the number of features added for ASP.NET Whidbey rivals the number of features added for the original release. That is, ASP.NET Whidbey looks very cool.

In this article, we’ll point out some of the changes to ASP.NET that are going to make it much easier to develop Web sites in a fraction of the time it takes now. (Note that this article was written in September 2003, using the Whidbey Alpha Milestone 2 release. By the time you read this, a newer version may be available with more and/or different features.)

Creating a New Web Application
The changes start when you first attempt to create a new Web project. If you select File and then New Project, you won’t find an option to create a Web project. Instead, in the current version of Whidbey, create a new Web project by selecting File and then New Web Site. Figure 1 shows the New Web Site dialog box.

Fast Facts
ASP.NET Whidbey includes a ton of new, useful functionality. Microsoft has encapsulated a lot of code you previously needed to write yourself, and has created simple, templated components for most scenarios. Need to authenticate users, allow for site personalization, or bind to just about any data source? It’s all in there.
The ASP.NET Internet Site Template

Figure 2: A Master Page allows you to create a common look and feel and navigation for your complete site in one location. Each page uses this master page.

The ASP.NET Internet Site template makes a great starting place for an Internet site with public pages, and possibly a secure area for members. This template provides a complete site, with menus, login pages, secure folders, and a master page that you can modify to suit your own needs. (More on master pages later, but these pages allow you to create a “base page” into which you can insert your own content. This allows your site to have a consistent look and feel with very little effort.) This site also supplies pages for articles, and a picture gallery for members. If you’ve used the ASP.NET Community Starter Kit, you’ve got the basic idea.

Figure 2 shows the default page built for you when you use the ASP.NET Internet Site template. This page shows off many of the new features of ASP.NET Whidbey. Most important, this page uses the new Master Page feature to create the basic look that’s shared across all the pages within the site, and provides the content on the left and top portions of the page. The master page allows you to create a common look and feel for each page, but allows each page to have its own distinct content area.

The master page created by the Internet Site template includes a LoginView control at the upper right of the page that shows three hyperlinks: login, register, and contact. Once you log in, these three hyperlinks change automatically to logout, profile, and contact. In other words, the LoginView control manages the links based on the authentication state of the logged in user, so you don’t have to do the work.

Figure 3: You can personalize pages using Web Parts.

On the sample page, you’ll also find a new SiteMapPath control that shows you how you got to your current location within the site. On the default page, the control just displays “Home”, but if you click on the Articles hyperlink on the left of the screen, then choose Article 1 from the tree view, you will see this control’s text change to display Home > Articles > Article 1.

The data-bound TreeView control used for navigation on the left side of this page gets its data from an XML file. This special XML file, named app.sitemap, contains the data for navigating your site. You associate the app.sitemap file with a SiteMapDataSource control, and this SiteMapDataSource then becomes the data source for this TreeView control.

The ASP.NET Intranet Site Template
Selecting the ASP.NET Intranet Site template creates a site that acts as a corporate portal. In addition to all the other features supplied by this page, as shown in Figure 3, the Intranet Site template supports personalization?you can click the Personalize This Page link, and then click and drag Web Parts around the page as shown in Figure 4.

Figure 4: Personalization allows you to move Web Parts around on the page, store the locations, and retrieve the locations when you later browse to the same page.

The new locations are saved for you, and when you next view the same page, the parts display as you last saved them. (This feature requires Microsoft Internet Explorer 5.5 or later.) The master page in this template site contains a LoginName control in the upper right corner of the page (taking advantage of Windows authentication to log in users), and a DataList control that displays the site map data from the DataSetDataSource control on the left side of the page. (This brings up another new feature?you can bind a DataSetDataSource control to an XML file directly. In that way, this DataList control retrieves data from an XML file, bound to the DataSetDataSource control that creates a DataSet based on data in the XML file.)

To create a Web Part, you simply create a user control and then add the control into a WebPartZone control. The WebPartZone control acts as a container for your user control, making it editable, customizable and moveable within the confines of any of the Web Part zones on the page. You’ll learn more about creating Web Parts later in this article.

What Happened to IIS?
It’s clear, given the examples so far, that Visual Studio .NET Whidbey makes it a lot easier to create and manage Web projects on your development computer. It appears that some magic is going on?you’re getting Web sites created without the hassle of creating virtual directories! If you’ve ever created lots of sample sites on your development computer and then had the problem of cleaning up your IIS folder, deleting the Web cache folder, and making sure that you had a virtual root set up for every project you retrieved from other developers, you’ll rejoice at the concept of not needing to involve IIS in your Web development. What’s going on, then? How can you create Web sites and run them without needing to create virtual directories?

You’ll rejoice at the concept of not needing to involve IIS in your Web development.

If you create a Web site using any of the first three templates and then you run the project, you will notice an icon and balloon appearing in the lower right hand corner of your screen, like Figure 5. This balloon indicates that you’ve started up the Visual Web Developer Web Server (similar to the Cassini server that ships as part of the Web Matrix product). This Web Server runs your site using a random port off of the localhost location, and doesn’t require you to create a virtual directory from which to run your sites locally.

Figure 6: Managing users, roles, and permissions is now handled through a Web interface.

Authentication Tasks Made Easier
Although managing authentication in ASP.NET has never been terribly difficult, it’s always been something that every developer must handle individually, for each application. Realizing that this is a common requirement for every application, Microsoft has created a series of security-related controls in this new version. You’ll certainly need to write less code, given the set of template-driven controls you’ll find on the Security tab of the control toolbox. You’ll be creating login pages with little or no code.

The new security-related controls utilize classes in the System.Web.Security namespace, and this namespace includes several new classes that make it easier to manage user, password, and role maintenance. These classes can use any data provider to store information about your users, passwords, and roles in just about any data store you wish.

In order to make it easier for developers to manage their sites’ users, roles, and permissions, Microsoft includes a Web-based interface that handles all the details for you. Select Website, and then ASP.NET Configuration to display a set of pages, as shown in Figure 6, to manage security. You can store your data in either SQL Server tables or Access/JET MDB files. Use this wizard to set up a new database with all of the necessary tables, and to add, edit, and delete users, roles, and permissions.

The Web Application Administration Wizard creates quite a few tables for you. Figure 7 shows a sample of these tables in an Access database for a sample application. (You’ll find this database in the Data folder of an Intranet application you create using the ASP.NET project templates, as well.)

Figure 7: Quite a few membership tables are created for the security system in ASP.NET.
Figure 8: The Login control makes checking user membership quick and easy.

The Login control, shown in Figure 8, can be dropped onto any Web page. This control uses the .NET Framework’s membership classes to check whether the user is authenticated?in other words, if the user is in the aspnet_Users table in your data store. If the user exists, and the password checks out, an authentication cookie is issued so ASP.NET knows the user has been authenticated. Like many of the new controls, the Login control supports templates, so that you can change just about every aspect of its appearance on the page. In Figure 8, we selected one of the supplied auto-formats.

Figure 9: The LoginView allows you to manage which controls are displayed based on the user’s logged-in status.

Authentication Tasks Made Easier (cont.)
The LoginView control automatically detects whether a user is authenticated, and displays an appropriate template. By default, you get two templates when you drag a LoginView control onto your Web page: AnonymousTemplate and LoggedInTemplate. You add any controls you wish to each template. For example, in the Internet site you saw earlier, the AnonymousTemplate has a hyperlink that displays login. This link was displayed when a user first entered the site. After the user logs into the site, the LoggedInTemplate is displayed and the hyperlink now displays logout. You may also add new templates, each associated with a user role. Using this technique, each role you define in the system may display different hyperlinks within the LoginView control. Figure 9 shows how you might edit the AnonymousTemplate template within the sample page’s LoginView control.

The LoginStatus control (see Figure 10) can display either text or an image to represent the user’s current logged-in status within an application. You can set up your site so that when users who aren’t logged in click the LoginStatus control, they’re redirected to the login page. Similarly, you can control the behavior when a logged-in user clicks the control. You can redirect to a logout page, refresh the current page, or redirect to the login page. No matter how you use this control, it can save you the effort of setting up the appropriate redirection and status indicators.

Personalization Support on Web Pages
Lots of sites allow you to personalize content (one of us has spent far too many hours adding and modifying content on his MyYahoo! portal), but Microsoft kicked this technology up a notch by adding support for dragging and dropping Web Parts in its SharePoint products. By designing Web Parts using the interfaces required by SharePoint, developers can easily create intelligent, personalized “widgets” that can be displayed on Web pages.

In Visual Studio .NET Whidbey, it’s easy to create the same sort of behavior. Once you’ve set up your page with appropriate Web Part container controls, you can move content areas around just by entering a special edit mode, then dragging and dropping areas of your Web page to a new location. You can customize titles of sections, as well.

For example, when you create a site using the ASP.NET Intranet Site template, the default.aspx page includes a hyperlink in the upper-right corner with the caption “Personalize this Page.” Once you click that link, you are allowed to drag and drop the Web Parts from one location to another on the page. In addition, if you click the down arrow in the title area of one of the Web Parts, you can edit certain characteristics. For example, Figure 13 shows default.aspx with one of its parts being edited during personalization. Once you are done, click the End Personalization link to persist your changes. On subsequent visits to the page, your settings are retrieved and applied to the various Web Parts on the page.

Creating Your Own Web Part
It’s easy to look at ASP.NET Web Parts and see them in action, but perhaps you’d like to create your own. Perhaps you’re thinking they must be incredibly difficult to create. You’d be wrong?they’re actually quite simple to create. Creating a Web Part can be as simple as dragging a user control into a WebPartZone control. To demonstrate how simple it can be to create a customizable Web Part, follow these steps.

  1. Create an Intranet site, using the ASP.NET Intranet Site template.
  2. Select Website and then Add New Item.
  3. From the list of templates, select Web User Control, and set the name to MyCalendar.aspx.
  4. Add an instance of the ASP.NET Calendar control to your new user control. (Select the Core tab on the Toolbox window to select the ASP.NET server controls.)
  5. Save your changes.
  6. Open the default.aspx page within the page editor, and select Design view by clicking on the Design tab at the bottom of the window.
  7. Click on the right WebPartZone controls where you see other controls such as Daily Links and My Weather. Click the WebPartZone’s smart tag and select Edit Templates.
  8. Drag and drop an instance of the MyCalendar.ascx user control from the Solution Explorer to the default.aspx page immediately below the Daily Links, so it looks like Figure 14.
  9. On the Common WebPartZone Tasks smart tag, click End Template Editing.
  10. Run the application, and you will see your calendar appear just below the Daily Links. You can click the Personalize This Page link to set properties for this new Web Part.
Figure 15: The bulleted list control bound to a data source makes creating lists quick and easy.

Investigating New Server Controls
As if all the previous functionality wasn’t enough, the current version of ASP.NET Whidbey has added 38 new server controls! Obviously, we can’t describe them all here (we haven’t even managed to investigate them all), we’ll try to point out some of the interesting new controls, focusing on new user interface elements and new data source controls.

It’s also interesting to note that in ASP.NET Whidbey, all the server controls are device-aware. Rather than requiring you to create separate applications for rich browsers and for mobile devices, all the controls now can be used for either type of browser. ASP.NET renders the output correctly, depending on the type of device making the request for the page.

The BulletedList control allows you to display a bulleted list in almost any format you wish. (You could do this in ASP.NET 1.x using a Repeater control, but that seemed like a lot of effort.) All you have to do now is to bind this control to a data source (such as the DataSetDataSource), set the BulletStyle property to one of its many options, and it produces output that looks like Figure 15.

Figure 16: The TreeView control is ideal for navigation on Web sites.

Although it was possible in ASP.NET 1.x to download and incorporate a somewhat complex TreeView control, ASP.NET Whidbey includes a full-featured, easy-to-use TreeView control. With little or no code, you can easily bind the TreeView control to a data source, and display hierarchical data. Figure 16 shows a simple menu structure you can generate with just a little XML data and by setting a few properties.

To create your own TreeView control as shown in Figure 16, follow these steps:

  1. In the Solution Explorer window, right-click the Data folder, and select

Add New Item from the context menu.

  1. Select XML File from the list of templates, and name the new file Menus.xml.
  2. In the Solution Explorer
  3. window, double-click Menus.xml to load it into the code editor, and add the following XML data. Save the file when you’re done.
Figure 17: The TreeViewBindings Editor assists you in getting the different levels of your tree view hooked up to your XML file.
  1. In the Solution Explorer window, right-click on the topmost node (the root folder) and select Add New Item from the context menu. Add a new Web Form, and name the page TreeView.aspx. If necessary, switch to Design view.
  2. From the Toolbox window, select the Data tab, and drag an XmlDataSource control onto your page.
  3. From the new control’s smart tag, select the Configure DataSource link. In the Data File text box on the Configure Data Source dialog box, enter the path to your XML file (Data/Menus.xml) or click the browse button to browse to the location. Click Finish to dismiss the dialog box.
  4. In the Toolbox window, select the Core tab, and add a TreeView control to the page.
  5. In the TreeView control’s smart tag, select the Auto Format link, and select the Windows Help option.
  6. In the TreeView control’s smart tag, select the Connect to DataSource link, and select the XmlDataSource1 option from the list of available data sources.
  7. Select the Edit Bindings option from the smart tag, displaying the TreeView Bindings Editor dialog box.
  8. In the Available Bindings list, select the top item, Menus, and then click Add.
  9. In the Binding Properties grid to the right, set the Text property to Help Topics.
  10. In the Available Bindings list, select the next item, Menu, and then click Add.
  11. In the Binding Properties grid to the right, set the TextField property to Text. (This indicates which attribute of the Menu item within the XML you’d like to display for this node in the TreeView control.)
  12. In the Available Bindings list, select the next item, SubMenu, and then click Add.
  13. In the Binding Properties grid to the right, set the TextField property to Text.
  14. Uncheck the Auto-Generate Bindings check box in the lower left of this screen. Your dialog box should look like Figure 17.
  15. Click the OK button to save the changes.
  16. In the Solution Explorer window, select TreeView.aspx, and press F5 to run your project. Your page appears, showing the TreeView control as in Figure 16. (Note that pressing F5 now runs the selected page?you don’t have to set the start page explicitly.)

Data Binding Controls
ASP.NET Whidbey provides several options for binding to data. You’ve already seen the SiteMapDataSource, XmlDataSource, and DataSetDataSource controls in use, but these are just a few of the different data sources provided by ASP.NET for use in Web pages. You can drag each of the controls discussed in the following paragraphs from the Data tab of the Toolbox window to any page, and you can bind just about any ASP.NET server control to any of these data sources.

The SqlDataSource control allows you to retrieve data from SQL Server, much as the SqlDataAdapter control did for you in earlier versions of ASP.NET. The real difference is that this control encapsulates both the connection and the command information (whereas the older controls required a separate connection control). You’ll find that this control makes it easy to create the SELECT command, and you can then automatically generate the INSERT, DELETE, and UPDATE commands. You have the option of inferring parameters, and can specify how and when the parameter values get fulfilled. Finally, you also have the option of retrieving the schema at design time or at runtime. (Note that the SqlDataSource control uses OLE DB by default, just like the similar controls in the previous version of Visual Studio .NET. You can modify this behavior by tweaking the connection string yourself in the page’s source.)

The XmlDataSource control allows you to set up a data source that retrieves its data from an XML stream. You can specify an XML file name, and can optionally specify an XSL transform, so that you can transform the data before binding it to a control. For example, you may need to transform the raw XML before binding it to a TreeView control. You can also specify an XPath query, so that you can filter the data that’s returned from the data source.

The DataSetDataSourcecontrol makes it easy to bind to an existing DataSet. Of course, because the DataSet is serialized as XML, this means you can also use the DataSetDataSource control to bind other controls to XML. Unlike the XmlDataSource control, the DataSetDataSource control does not allow you to perform XSL transforms or XPath queries on the XML data.

The ObjectDataSource control will turn out to be, we’re guessing, one of the most exciting new data binding features in this release of .NET. This control will make all the n-tier purists out there happy?finally, you can bind the user interface to middle-tier objects, as opposed to DataSet objects directly. This control allows you to specify the name of a class and the name of a method within that class that returns a DataSet. We intend to spend a lot more time investigating the possibilities of this control, as we work with later versions of the product.

The AccessDataSource allows you to retrieve information from an Access database. (Actually, MDB files are databases provided by the Jet database engine. Microsoft Access has little to do with it besides being the major consumer of databases created using the Jet database engine, but the name continues to stick.) This control allows you to specify the name of the Access file instead of having to use an OLEDB provider. Otherwise, the control works just like the SqlDataSource control.

The SiteMapDataSource control allows you to treat a site map as a data source for other controls (most specifically, the TreeView control, as you’ve already seen). This control retrieves data from a special XML file named app.sitemap. The XML file has a very specific schema associated with it, so you must be careful to follow the rules. The following code shows an example from the default Intranet Site template: You can see the Home and the Sales nodes in this XML, and those are the nodes that show up in the upper-left corner of the master page in the default Intranet site:


It looks to us like the ASP.NET team at Microsoft has spent a great deal of time looking at the kinds of sites people create. They’ve done a great job encapsulating much of the common code and functionality into server controls, so developers can spend more of their time on designing great sites and less on rebuilding components other developers also have to build. From the ability to create master pages that define the look of an entire site, to the new security and personalization controls, to the simpler data sources, we’re totally impressed with what we’ve seen in the new version. We can hardly wait to get started building applications using all these new toys. One thing’s for sure: sites we build using ASP.NET Whidbey require a lot less code than those we wrote for earlier versions. And that’s a good thing.

See also  Comparing different methods of testing your Infrastructure-as-Code

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist

©2024 Copyright DevX - All Rights Reserved. Registration or use of this site constitutes acceptance of our Terms of Service and Privacy Policy.