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, andPortal starter kits.

By Brian Noyes

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

The Time Tracker Starter Kit (TTSK) represents aline-of-business Web application implemented with ASP.NET. It demonstrates manybest practices and techniques for building similar applications. Theapplication, as its name implies, is a time-tracking system for consultingfirms that allows consultants to log the amount of time they've spent workingon 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 ontheir teams, manage the tasks of their projects, and generate project- orresource-oriented summary reports and charts. Administrators can createaccounts and projects, and they can assign users to roles.

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

The TTSK's code is worth a look because some of itsfeatures overlap with best practices demonstrated in the Starter Kits I previouslycovered (see read Minethe Starter Kits and Explorethe Reports Starter Kit). Examples include the use of Data AccessApplication Blocks for data access; the generation of charts on the serverusing the Graphics and Bitmap classes; the use of collection classes fordecoupling your presentation tier from your data tier; and the nesting ofDataLists to achieve hierarchical display of related data in tables. In thisarticle, I will focus on several techniques the TTSK demonstrates not shown inthe other Starter Kits. These techniques include presenting pop-up inputdialogs, authentication and authorization techniques, exposing a mobile-deviceinterface, 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 edgesthat require some workarounds. I mention these in this article's code downloadin 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. Ifyou are working with the Visual Basic .NET or SDK versions of the kit, thesuffix of the project names will be slightly different (for example, VBVS,CSSDK, or VBSDK). Note that the code download for this article includes samplecode in both C# and VB, but it's geared for the Visual Studio versions of thekit, which use code behind for their pages. You can download any of the StarterKits 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 theway it incorporates a Microsoft Mobile Internet Toolkit (MMIT) mobile interfaceon the application so consultants in the field can use mobile devices to submittimecard entries for the projects they are assigned to. The TTSK consists oftwo Web applications. The main application is the TTWebCSVS project, whichcontains the desktop users' Web application and the business-logic anddata-access layers. The second application is a TTMobileCSVS project, whichcontains only the MMIT Web application that provides the user interface formobile-device users. The only mobile page in the kit is the TimeSheet.aspxpage, which contains several forms. Keep in mind that a single page in an MMITWeb application can contain multiple related mobile-device forms, as in theTimeSheet.aspx page. This article's code download contains an additional pageto show you how to extend the application's mobile-interface side. It adds aform to allow project managers who log in from a mobile device to manageproject members for a team (see Figure 2).

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

To create this additional functionality for the mobile Webapp, I first added a new page to the TTMobileCSVS project namedAssignTeamMembers.aspx. For debugging purposes, I enabled Integrated WindowsAuthentication in IIS for this Web application because it is required to run adebug session from Visual Studio. I positioned the controls on the form usingthe designer as I would for any other Web form. Note that mobile Web forms useflow layout because they need to target devices such as mobile phones andpersonal digital assistants, so you have restricted design capabilities foryour form. The key thing to remember when designing mobile Web forms is to keepit simple! Don't require the user to have a keyboard and mouse to use yourinterface effectively. You need to visualize the interface on an input-impaireddevice, and you certainly should test your app on some of these devices beforeputting it into production.

You also need to realize that most mobile controlsequivalent to normal ASP.NET server controls do not have the same level offunctionality because many devices that display them have certain limitations.For example, the SelectionList control used in the sample code does not haveAutoPostBack capability like its server-control cousin. So you need to add aCommand button to the form to force a postback when you want to refresh pagecontents based on listbox selections. The AssignTeamMembers.aspx mobile formsimply contains a few labels, three SelectionList controls, and three commandbuttons.

The other thing used by the page I implemented - like theTimeSheet.aspx page - is a Styles.ascx user control that contains a StyleSheetcontrol from MMIT. Although most mobile devices won't support Cascading StyleSheets (CSS), you still should centralize your look-and-feel definition as muchas you can and ensure the presentation is as consistent as possible acrossdevices. The MMIT StyleSheet control and Style tags let you do this, and byputting the StyleSheet control inside a user control, you apply the stylessimply by dragging the user control onto your mobile pages and using attributesto reference the StyleSheet control in your page controls' attributes. Forexample, 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 andlblProjects labels result in the application of styles defined in theStyles.ascx user control so that those labels look consistent with labels ofsimilar function in the application's other forms.

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

Make Dialogs Interactive

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

A better approach is to do the same thing you would whendesigning a desktop Windows application: Present the user with a dialog thatallows him or her to enter data, then update the main page based on the dataentered. In an ASP.NET application, doing so might not be obvious. The TTSKincludes this kind of approach for allowing the user to enter a date from acalendar control without wasting the real estate on the main page. In variousplaces in the application, the page contains only a small graphic representinga calendar, and if the user clicks on it, he or she gets a pop-up windowcontaining a calendar from which to select a date.

As you might have guessed, the underlying functionality tomanage these pop-up windows is implemented in client-side JavaScript. You mightwant to do something similar in your own apps. In some cases, you might need toforce a postback of the main page if the changes made in the pop-up dialogchange background data (such as data used by the main page to render itsinformation). In other simpler situations, you simply could update a control onthe main page with some value entered in the pop-up without requiring anotherround trip to the server.

To simplify how to do these things separately from theTTSK, 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 thedialog window. When the main page loads, it reads in a string from a text fileto populate the textbox. The pop-up dialog itself is simply another .aspx pagethat contains some additional logic to close itself when the user clicks onCancel or OK. The pop-up dialog code also updates the page that launched thepop-up, either by causing a postback on the main page so it can refresh itselffrom background data or, more simply, by updating a control value on the clientside. The glue that ties it all together is a small amount of JavaScript thatincludes a function to pop up the dialog initially, and another couple offunctions either to cause a postback or to update a control when called fromthe pop-up window itself (see Figure 3). See the download code for more detailson 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 longway toward providing user interactivity. You can launch an .aspx page in apop-up window and pass parameters to it with the query string, then you canpass data back to controls on the parent form using the HTML Document ObjectModel (DOM).

Use Cookies for Roles and CustomPrincipals

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

Other than this use of the FormsAuthenticationinfrastructure, the rest of the application uses Windows authentication. Thislets the app reap the benefits of the strong security model and provide a moreseamless user experience if running the application from a Windows network(saving the user from logging in). It also lets the app access informationabout the logged-in user from the Active Directory (AD) or the Windows SecurityAccount Manager (SAM) to avoid the hassle of creating and managing duplicateuser information (such as the user's full name and contact information). ADirectoryHelper class encapsulates the code for reading user information fromAD or SAM.

Another feature the TTSK demonstrates nicely is how toinsert custom edit controls in a DataGrid while in edit mode. The DataGrid usedto display the user's time entries on the Log page allows the user to edit theitems in the grid directly after they have been entered using the form (seeFigure 1). By default, when a DataGrid is placed into edit mode, all the entryfields are rendered as TextBox controls and as a consequence the user easilycould 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 andday) are constrained to allowable values by using a dropdown listbox populateddynamically by the page. To insert custom controls in this manner, instead ofusing the default TextBox controls, you use an EditItemTemplate in theDataGrid. You can add this programmatically from the code behind, but often yousimply can use the template XML markup in the declaration of the DataGrid inthe .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> elementwithin an <asp:templatecolumn> in an .aspx page containing a DataGridallows you to specify the control that will be presented in that column whenthe 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 ofd?j? vu - and with good reason. For the most part, CSK and PSK are the same asthe IBuySpy Portal and Store, with some minor changes or improvements. This isnot to say they are not worthwhile. Quite the contrary. If you have not checkedthem 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 ofyears using the IBuySpy Portal and Store SDKs because they give you a packageyou can mold quickly and easily, starting with the fictional business theyrepresent in the SDK into a real online business or organizational presence.

CSK presents an application architecture for creating ane-commerce storefront using ASP.NET, including product catalogs anddescriptions, order processing, and a shopping-cart metaphor. It includes acleanly designed three-tier architecture that also demonstrates othercapabilities, such as the use of forms authentication for user login andauthorization, and exposes an XML Web service for business-to-businesstransactions. This kit looks remarkably similar to the IBuySpy Store SDKbecause that's basically what it is. The code hardly differs at all - only someminor relabeling, renaming of files, and data changes so it's presented as CSKinstead of the IBuySpy Store.

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

In the IBuySpy Portal, all the data that determines thelayout and structure of the site is stored in the database, along with thedynamic content the site presents at run time. In PSK, this site-structureinformation (Portals, Tabs, and Modules) has been moved out of the database andinto 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.netdescribes. First, the move simplifies the site-management code. But morecompelling is that, because this information is mostly static, PSK uses ASP.NETcaching to load the information once and keep it in memory, and it avoids roundtrips to the database every time someone hits a page.

Well, that completes our mining adventure, spelunkingthrough the vast capabilities of the ASP.NET Starter Kits. By now, you haveseen that these kits go far beyond the standard concept of code samples; theygive you whole architectures and applications you can reuse directly toimplement the sites you need.

The sample code in thisarticle 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 SolutionDeveloper with more than 12 years of programming, design, and engineeringexperience. Brian specializes in .NET architecture, design, and coding ofdata-driven Web and Windows applications, data-access and XML technologies, andOffice 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 Minethe Starter Kits I explored how to use the Community Starter Kit toimplement collaborative and dynamic content-driven Web sites. At that time thisstarter kit was still in beta. The good news: The 1.0 version now has beenreleased and is available at http://www.asp.net. The bad news: Manychanges have been made to the architecture that render obsolete some of thethings I presented in that article. But, there's more good news: Microsoft hasadded many valuable features from the feedback received during beta that willmake it worth your while to upgrade if you adopted the starter kit in beta, andhopefully you can overcome the migration effort. The overall architecture of the 1.0 release is the same, but theway skins are handled has changed a little so you won't be able to run the codeI 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 enginelocated those controls using a FindControl call. In version 1.0, customcontrols are used for all the expected elements on a page, so you need toupdate your markup code to reference those custom controls based on their typeinstead of using the IDs to identify them to the code behind. This is the mainbreaking change.

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

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