asp:feature

LANGUAGES: C# | VB .NET

ASP.NET VERSIONS: 1.0 | 1.1

 

Finishing the Job

In the final installment of the Starter Kits series, learn to make the most of key features in the Time Tracker, Commerce, and Portal starter kits.

 

By Brian Noyes

 

In my previous two articles, I introduced you to three of Microsoft's new - and free - ASP.NET Starter Kits. In this article I'll round out the series by explaining the features of the remaining kits: the Time Tracker, Portal, and Commerce starter kits.

 

The Time Tracker Starter Kit (TTSK) represents a line-of-business Web application implemented with ASP.NET. It demonstrates many best practices and techniques for building similar applications. The application, as its name implies, is a time-tracking system for consulting firms that allows consultants to log the amount of time they've spent working on a project on the Web from a desktop machine or mobile device (see Figure 1). TTSK also allows managers to track the time recorded by the consultants on their teams, manage the tasks of their projects, and generate project- or resource-oriented summary reports and charts. Administrators can create accounts and projects, and they can assign users to roles.

 

Figure 1. The Time Tracker Starter Kit allows consultants to enter the time they've spent working on projects. Project managers can assign team members, add tasks, or generate summary reports.

 

The TTSK's code is worth a look because some of its features overlap with best practices demonstrated in the Starter Kits I previously covered (see read Mine the Starter Kits and Explore the Reports Starter Kit). Examples include the use of Data Access Application Blocks for data access; the generation of charts on the server using the Graphics and Bitmap classes; the use of collection classes for decoupling your presentation tier from your data tier; and the nesting of DataLists to achieve hierarchical display of related data in tables. In this article, I will focus on several techniques the TTSK demonstrates not shown in the other Starter Kits. These techniques include presenting pop-up input dialogs, authentication and authorization techniques, exposing a mobile-device interface, and inserting custom controls within a DataGrid for value editing. This Starter Kit was still in beta at press time and it has some rough edges that require some workarounds. I mention these in this article's code download in case you are still running the beta version.

 

For this article, I worked with the Visual Studio .NET C# version of the kit, so you will see "CSVS" appended to the project names. If you are working with the Visual Basic .NET or SDK versions of the kit, the suffix of the project names will be slightly different (for example, VBVS, CSSDK, or VBSDK). Note that the code download for this article includes sample code in both C# and VB, but it's geared for the Visual Studio versions of the kit, which use code behind for their pages. You can download any of the Starter Kits and their various versions at http://www.asp.net/Default.aspx?tabindex=9&tabid=47.

 

Go Mobile

One of the first things to check out in the TTSK is the way it incorporates a Microsoft Mobile Internet Toolkit (MMIT) mobile interface on the application so consultants in the field can use mobile devices to submit timecard entries for the projects they are assigned to. The TTSK consists of two Web applications. The main application is the TTWebCSVS project, which contains the desktop users' Web application and the business-logic and data-access layers. The second application is a TTMobileCSVS project, which contains only the MMIT Web application that provides the user interface for mobile-device users. The only mobile page in the kit is the TimeSheet.aspx page, which contains several forms. Keep in mind that a single page in an MMIT Web application can contain multiple related mobile-device forms, as in the TimeSheet.aspx page. This article's code download contains an additional page to show you how to extend the application's mobile-interface side. It adds a form to allow project managers who log in from a mobile device to manage project members for a team (see Figure 2).

 

Figure 2. Adding functionality to the mobile portion of the TTSK is as simple as implementing new MMIT pages and forms.

 

To create this additional functionality for the mobile Web app, I first added a new page to the TTMobileCSVS project named AssignTeamMembers.aspx. For debugging purposes, I enabled Integrated Windows Authentication in IIS for this Web application because it is required to run a debug session from Visual Studio. I positioned the controls on the form using the designer as I would for any other Web form. Note that mobile Web forms use flow layout because they need to target devices such as mobile phones and personal digital assistants, so you have restricted design capabilities for your form. The key thing to remember when designing mobile Web forms is to keep it simple! Don't require the user to have a keyboard and mouse to use your interface effectively. You need to visualize the interface on an input-impaired device, and you certainly should test your app on some of these devices before putting it into production.

 

You also need to realize that most mobile controls equivalent to normal ASP.NET server controls do not have the same level of functionality because many devices that display them have certain limitations. For example, the SelectionList control used in the sample code does not have AutoPostBack capability like its server-control cousin. So you need to add a Command button to the form to force a postback when you want to refresh page contents based on listbox selections. The AssignTeamMembers.aspx mobile form simply contains a few labels, three SelectionList controls, and three command buttons.

 

The other thing used by the page I implemented - like the TimeSheet.aspx page - is a Styles.ascx user control that contains a StyleSheet control from MMIT. Although most mobile devices won't support Cascading Style Sheets (CSS), you still should centralize your look-and-feel definition as much as you can and ensure the presentation is as consistent as possible across devices. The MMIT StyleSheet control and Style tags let you do this, and by putting the StyleSheet control inside a user control, you apply the styles simply by dragging the user control onto your mobile pages and using attributes to reference the StyleSheet control in your page controls' attributes. For example, in the AssignTeamMembers.aspx page, these tags are declared:

 

<mobile:stylesheet id="Stylesheet1"

ReferencePath="Styles.ascx"

runat="server">

</mobile:stylesheet>

<mobile:Form id="Form1"

runat="server" StyleReference="Form">

<mobile:Label id="lblTitle"

runat="server" StyleReference="Title">

Manage Team Members

</mobile:Label>

<mobile:Label id="lblProjects"

runat="server" StyleReference="list-header">

Projects</mobile:Label>

...

</mobile:Form>

 

The StyleReference attributes on the lblTitle and lblProjects labels result in the application of styles defined in the Styles.ascx user control so that those labels look consistent with labels of similar function in the application's other forms.

 

The key thing to notice about the mobile user interfaces defined in the TTMobileCSVS project is that they contain no business logic. Because the business logic and data access of the original Web application are well designed, the mobile pages can reuse the code from the desktop users' Web application. You could extend this even further by exposing this functionality to a rich client via a Web Service.

 

Make Dialogs Interactive

When designing a Web application that allows users to enter data interactively, you often need to prompt users to enter some data relevant to the main page on which they are working. But you don't want to send them off to another page only to enter that data then bring them back to the main page. This can result in a loss of context for the user, and it also can be difficult to manage all the state passing between pages.

 

A better approach is to do the same thing you would when designing a desktop Windows application: Present the user with a dialog that allows him or her to enter data, then update the main page based on the data entered. In an ASP.NET application, doing so might not be obvious. The TTSK includes this kind of approach for allowing the user to enter a date from a calendar control without wasting the real estate on the main page. In various places in the application, the page contains only a small graphic representing a calendar, and if the user clicks on it, he or she gets a pop-up window containing a calendar from which to select a date.

 

As you might have guessed, the underlying functionality to manage these pop-up windows is implemented in client-side JavaScript. You might want to do something similar in your own apps. In some cases, you might need to force a postback of the main page if the changes made in the pop-up dialog change background data (such as data used by the main page to render its information). In other simpler situations, you simply could update a control on the main page with some value entered in the pop-up without requiring another round trip to the server.

 

To simplify how to do these things separately from the TTSK, the download code includes a simple Web application named PopupHost, which has a single page with a read-only text control and a link to pop up the dialog window. When the main page loads, it reads in a string from a text file to populate the textbox. The pop-up dialog itself is simply another .aspx page that contains some additional logic to close itself when the user clicks on Cancel or OK. The pop-up dialog code also updates the page that launched the pop-up, either by causing a postback on the main page so it can refresh itself from background data or, more simply, by updating a control value on the client side. The glue that ties it all together is a small amount of JavaScript that includes a function to pop up the dialog initially, and another couple of functions either to cause a postback or to update a control when called from the pop-up window itself (see Figure 3). See the download code for more details on how to tie the pages together using this script.

 

function openPopupWindow(href, qstring,width,height)

{

  var addr = href + '?' + qstring;  

  var params = 'width=' + width + ',height=' + height +

  ',toolbar=no,directories=no,location=no,' +

  'status=no,menubar=no,scrollbars=yes,' +

  resizable=yes';

  window.open(addr, 'Popup',params );

}

 

function CloseAndSetValue(id, newvalue)

{

  var doc = top.window.opener.document

  doc.forms[0].elements[id].value = newvalue;

  window.close();

}

Figure 3. A little client-side script can go a long way toward providing user interactivity. You can launch an .aspx page in a pop-up window and pass parameters to it with the query string, then you can pass data back to controls on the parent form using the HTML Document Object Model (DOM).

 

Use Cookies for Roles and Custom Principals

Another interesting technique the TTSK demonstrates is the use of cookies to store user-role information so a custom principal can be "rehydrated" on subsequent requests by the same user. Basically, the way this works is through an AuthenticateRequest handler in the Global.asax.cs code. The first request received from a user results in the construction of a FormsAuthenticationTicket, which is used to hold both user information and a UserRoles cookie. Then the FormsAuthenticationTicket information is added to the Response object as a set of encrypted cookies. On subsequent round trips, this cookie information is extracted and used to reconstitute the custom principal for that user quickly.

 

Other than this use of the FormsAuthentication infrastructure, the rest of the application uses Windows authentication. This lets the app reap the benefits of the strong security model and provide a more seamless user experience if running the application from a Windows network (saving the user from logging in). It also lets the app access information about the logged-in user from the Active Directory (AD) or the Windows Security Account Manager (SAM) to avoid the hassle of creating and managing duplicate user information (such as the user's full name and contact information). A DirectoryHelper class encapsulates the code for reading user information from AD or SAM.

 

Another feature the TTSK demonstrates nicely is how to insert custom edit controls in a DataGrid while in edit mode. The DataGrid used to display the user's time entries on the Log page allows the user to edit the items in the grid directly after they have been entered using the form (see Figure 1). By default, when a DataGrid is placed into edit mode, all the entry fields are rendered as TextBox controls and as a consequence the user easily could enter incorrect data, whether intentionally or not. On the Log page, while the grid is in edit mode, several entries (such as the project name and day) are constrained to allowable values by using a dropdown listbox populated dynamically by the page. To insert custom controls in this manner, instead of using the default TextBox controls, you use an EditItemTemplate in the DataGrid. You can add this programmatically from the code behind, but often you simply can use the template XML markup in the declaration of the DataGrid in the .aspx page (see Figure 4).

 

<edititemtemplate>

<asp:dropdownlist Width="100px" ID="EntryProjects"

AutoPostBack="True" CssClass="Standard-text"

DataSource="<%# ListUserProjects() %>" DataTextField="Name"

DataValueField="ProjectID" Runat="server"

OnSelectedIndexChanged="UserProjects_OnChange" />

</edititemtemplate>

Figure 4. Adding an <edititemtemplate> element within an <asp:templatecolumn> in an .aspx page containing a DataGrid allows you to specify the control that will be presented in that column when the grid is placed into edit mode.

 

Commerce + Portal = IBuySpy++

When you first start looking at the Commerce Starter Kit (CSK) and Portal Starter Kit (PSK), you are likely to get a strong sensation of d j vu - and with good reason. For the most part, CSK and PSK are the same as the IBuySpy Portal and Store, with some minor changes or improvements. This is not to say they are not worthwhile. Quite the contrary. If you have not checked them out before in detail, now would be as good a time as any to do so. Hundreds, maybe thousands, of Web sites have been built in the past couple of years using the IBuySpy Portal and Store SDKs because they give you a package you can mold quickly and easily, starting with the fictional business they represent in the SDK into a real online business or organizational presence.

 

CSK presents an application architecture for creating an e-commerce storefront using ASP.NET, including product catalogs and descriptions, order processing, and a shopping-cart metaphor. It includes a cleanly designed three-tier architecture that also demonstrates other capabilities, such as the use of forms authentication for user login and authorization, and exposes an XML Web service for business-to-business transactions. This kit looks remarkably similar to the IBuySpy Store SDK because that's basically what it is. The code hardly differs at all - only some minor relabeling, renaming of files, and data changes so it's presented as CSK instead of the IBuySpy Store.

 

PSK also closely resembles the IBuySpy Portal, with one significant architectural change. This kit presents a model for a business Web portal with dynamic and configurable content. It's quite similar to what you can do with the IBuySpy Portal and what you can do with the Community Starter Kit. I encourage you to take a good look at both before deciding which to use.

 

In the IBuySpy Portal, all the data that determines the layout and structure of the site is stored in the database, along with the dynamic content the site presents at run time. In PSK, this site-structure information (Portals, Tabs, and Modules) has been moved out of the database and into XML configuration files. Making this change has two significant benefits, as a post by Scott Guthrie in the PSK discussion forum on http://www.asp.net describes. First, the move simplifies the site-management code. But more compelling is that, because this information is mostly static, PSK uses ASP.NET caching to load the information once and keep it in memory, and it avoids round trips to the database every time someone hits a page.

 

Well, that completes our mining adventure, spelunking through the vast capabilities of the ASP.NET Starter Kits. By now, you have seen that these kits go far beyond the standard concept of code samples; they give you whole architectures and applications you can reuse directly to implement the sites you need.

 

The sample code in this article is available for download.

 

Brian Noyes is an associate of IDesign Inc. (http://www.idesign.net) and a trainer, consultant, and writer. He's a Microsoft Certified Solution Developer with more than 12 years of programming, design, and engineering experience. Brian specializes in .NET architecture, design, and coding of data-driven Web and Windows applications, data-access and XML technologies, and Office automation. He is a contributing editor for asp.netPRO and other publications. E-mail him at mailto:brian.noyes@idesign.net.

 

Changes to the Community Starter Kit

In Mine the Starter Kits I explored how to use the Community Starter Kit to implement collaborative and dynamic content-driven Web sites. At that time this starter kit was still in beta. The good news: The 1.0 version now has been released and is available at http://www.asp.net. The bad news: Many changes have been made to the architecture that render obsolete some of the things I presented in that article. But, there's more good news: Microsoft has added many valuable features from the feedback received during beta that will make it worth your while to upgrade if you adopted the starter kit in beta, and hopefully you can overcome the migration effort. The overall architecture of the 1.0 release is the same, but the way skins are handled has changed a little so you won't be able to run the code I provided in the June issue directly on the 1.0 version. In the beta version, the controls in skins were identified using IDs, and the code in the engine located those controls using a FindControl call. In version 1.0, custom controls are used for all the expected elements on a page, so you need to update your markup code to reference those custom controls based on their type instead of using the IDs to identify them to the code behind. This is the main breaking change.

 

But you can take advantage of new capabilities including content replication and HTML input. Content replication allows you to aggregate content from site to site using Web services. So content published on one Community Starter Kit site can be referenced by another Community Starter Kit site, and the content is made available via Web services. The HTML input capability lets you add static HTML content to any content area in the site, and this content is rendered (including the HTML markup you provide when you enter the content).

 

If you implemented a site using the beta version of the Community Starter Kit, I recommend you make the effort now to upgrade to version 1.0. All the support in the forums on http://www.asp.net will reference this version, and you probably will have a hard time getting people to spend time helping you with issues related to the beta.