oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Build a Web-Based Bug Tracking App
Pages: 1, 2, 3, 4, 5

Entering A Bug

Once the user logs in and clicks on Enter A Bug, the TBTReportBug.aspx page is displayed (see Figure 7).

Figure 7. TBTReportBug page

There are a few important things to notice about this page (after you get over how ugly it is). First, we don't ask the user to fill in many of the fields from the Bug and BugHistory tables. These include the BugID and BugHistoryID; each of these is automatically created by the database. Every new bug gets a new record in Bugs, as well as a new record in BugHistory, which is assigned a BugHistoryID of 1. Every time a bug is edited, a new record is created in BugHistories (with an incremented BugHistoryID), thus creating a set of BugHistory records for each Bug.

We also do not ask for the TimeStamp (applied automatically by the database) or the user's name (which we obtain with the following code):

string currentUser = Page.User.Identity.Name;

Three of the fields are drop-down lists: Severity, Status and Owner. The drop-downs are bound to individual SQLDataSources; the first two provide Select statements against the Severities and Statuses tables, respectively, and the third provides a select statement against the Users table:

&ltl;asp:SqlDataSource ID="OwnerDataSource" runat="server" 
  ConnectionString="<%$ ConnectionStrings:LoginConnectionString %>"
    SelectCommand="SELECT [UserId], [UserName] FROM 
       [vw_aspnet_Users] ORDER BY [UserName]">

This code is not, of course, written by hand, but instead is created by dragging the SQL DataSource control onto the page and clicking on the smart tag to configure it (see Figure 8).

Figure 8. Configuring the SQL DataSource

Reusing the Bug Entry Page

None of this would be tricky at all (in fact, you wouldn't really need to write any code), except that you want to be able to use this same page to edit a bug as well as to enter a new one (after all, you are collecting the same information). When you are editing a bug you will prefill the page with the most recent data for that bug.

Determining if you have reached this page to enter a new bug or to edit an existing bug is accomplished in the Page_Load method. You check two things: first, that you are not in a post back (that is, you arrived here from another page) and second, that the Select statement in the BugsDataSource control you will add to the page returns a non-null DataView. This works because you'll populate the BugsDataSource using a stored procedure spGetBug that takes a single parameter--a BugID:

Create PROCEDURE [dbo].[spGetBug]
@BugID int
   select  top 1 
   BugID, BugHistoryID, ShortDescription, LongDescription, Notes,
   sev.SeverityID as Severity,
   statistics as Status, 
   Owner from BugHistories bh
   join Severities sev on sev.SeverityID = bh.Severity
   join Statuses stat on statiStics = bh.Status
   where BugID = @BugID
   order by BugHistoryID desc

This code will return the latest bug history information (if any) for the BugID passed in as a parameter. Of course, that begs the question: how do you pass in that BugID? The answer is to stash the BugID of the bug you're editing into SessionState, and then instruct the DataSource control to retrieve its parameter from session state, as shown in Figure 9.

Figure 9. Retrieving parameter from session state

You'll see how to put the value into session state when we look at the Review page.

Pages: 1, 2, 3, 4, 5

Next Pagearrow