Workshop

Quiz

1.	True or False: Optimistic concurrency, if enabled, applies to inserting, updating, and deleting data.
2.	What conditions must be true in order for the SqlDataSource control's wizard to be able to automatically generate INSERT, UPDATE, and DELETE commands?
3.	How do we customize the editing interface of an editable GridView?
4.	When a web page visitor clicks on the Delete, Edit, or Insert buttons for the GridView or DetailsView, what sequence of events takes place?
5.	What two GridView events fire during the deletion process?

Answers

1.	False. Optimistic concurrency applies only to updating and deleting data. With inserting new records, there's no possibility that one user's insert will overwrite another's because both users are creating new data.
2.	The table being queried must have a primary key, and the SELECT statement specified must, at minimum, return this primary key.
3.	By default a GridView renders each BoundField as a TextBox Web control. To customize this editing interface, we need to convert the BoundField into a TemplateField. Then, we can edit the field's EditItemTemplate, making whatever changes are necessary.
4.	When the user clicks on one of these buttons, the ASP.NET page is posted back. Upon postback, the GridView or DetailsView notes that the Edit, Delete, or Insert button was clicked and raises the first of two events: for the GridView, RowDeleting for deleting, and RowUpdating for updating; for the DetailsView, ItemDeleting for deleting, ItemUpdating for updating, and ItemInserting for inserting. Next, the data Web control's associated data source control has the appropriate InsertCommand, UpdateCommand, or DeleteCommand command invoked, which sends a SQL statement to the database, inserting, updating, or deleting the record. Finally, the data Web control signals that the data modification has completed, raising the RowDeleted or RowUpdated event for the GridView and ItemDeleted, ItemUpdated, or ItemInserted for the DetailsView.
5.	RowDeleting and RowDeleted.

Exercises

1. In the "Allowing Users to Delete Data" section, we examined how to use the GridView to allow users to delete a record from the GridView. In that section I mentioned that when the user clicks the Delete button, a postback ensues and the GridView, before instructing its data source control to delete the data, raises the RowDeleting event. If we want the delete to be canceled if some condition is met, we can create an event handler for this event and determine whether to cancel the delete.

   Your task for this exercise is to create an ASP.NET page that lists the books from the Books database table in a GridView that supports deleting. In addition to this GridView control, add a Label Web control on the page with the ID deleteFailed, the Visible property set to False, and the Text property value "Why oh why would you want to delete this book?". (When we set the Visible property to False, this control won't be rendered, so it won't appear in the user's browser until, on a postback, we set this property to true.)

   Next, create an event handler for the GridView's RowDeleting event. This event handler will be passed as its second parameter an object of type GridViewDeleteEventArgs, which has a property named Cancel. We can stop the user-initiated delete by simply setting this Cancel property to TRue. Additionally, this class has a property of type Values, which we can use as follows to grab a value from the row that the user is attempting to delete:

   e.Values(columnName) 

   Your task is to cancel the delete and have the deleteFailed Label displayed if the user attempts to delete a book authored by yours truly (Scott Mitchell). If the user is deleting some other author's book, hide the deleteFailed Label and let the delete continue unabated.

   Here's a snippet of code to get you started; this will go inside the RowDeleting event handler:

   If e.Values("Author") = "Scott Mitchell" Then   ... Else   ... End If 

2. In the "Customizing the Editing Interface and Updating Rules" section, we saw how to use TemplateFields to customize a particular field's editing interface. In this hour we looked at customizing the Price field to include both a RequiredFieldValidator and a CompareValidator. These two validation controls ensured that the user provided a currency value for the Price that was greater than or equal to zero.

   Please complete what we started here, adding RequiredFieldValidators to the Title, Author, YearPublished, and PageCount fields. Also add CompareValidator controls to the YearPublished and PageCount fields. The CompareValidator controls should ensure that both fields are integers that are greater than zero.

3. In addition to adding validation controls to a TemplateField's EditItemTemplate, we can also replace the TextBox Web control with a different Web control. For this exercise, customize the editable interface for the LastReadOn field, replacing the TextBox with the Calendar Web control.

   To accomplish this, convert the LastReadOn field to a TemplateField. Next, delete the TextBox control from the EditItemTemplate and drag a Calendar control from the Toolbox into the EditItemTemplate. At this point test the functionality in the browser. You'll see that when the user tries to edit a row, a calendar is displayed in the editable row's LastReadOn field. However, no date is selected in the calendar (even if there's a LastReadOn value), and if you select a date from the calendar and click Update, the value is not saved.

   To have the current value displayed in the Calendar Web control and to have the user's selected value persisted back to the database, we need to use a data binding expression that assigns the LastReadOn field to the Calendar control's SelectedDate property. We can accomplish this through the Design tab by going to the Calendar control's smart tag and clicking on the Edit DataBindings link. This will bring up the DataBindings dialog box. Simply select the appropriate Web control property from the list on the left (SelectedDate) and then select the data source control field to bind to this value from the drop-down list on the right (LastReadOn). Make sure the Two-way Databinding check box is checked.

   After making this change, take a moment to test the page in a browser. If you edit a book that has a LastReadOn value, the Calendar control's SelectedDate property will be assigned to the Calendar. Furthermore, whatever date is selected in the Calendar control is what is saved as the LastReadOn value when the Update button is clicked. However, as you may have noticed, when the row is made editable, the Calendar control shows the month and year of the value of its VisibleDate property (which defaults to the current date). So if the LastReadOn value of the editable row is November 11, 2005, but the current date is March 13, 2006, you'll have to click back through the months to November to be able to see the selected date. Obviously, we want the month and year of the LastReadOn date to be shown when a row is first made editable. To accomplish this, go back to the Calendar's DataBindings dialog box and bind the VisibleDate property to the LastReadOn field value, but this time make sure Two-way Databinding is unchecked.

   At this point the editable GridView should work as desired with rows that have a LastReadOn value; however, for those rows where this value is Null, you will get an exception when trying to edit. Why this happens, as well as why we had the Calendar's SelectedDate property use two-way databinding versus the one-way databinding used by the VisibleDate property, are topics we'll discuss in Hour 19, "Defining a Site's Structure and Providing Site Navigation."