Using the XmlEditGrid ControlJust in case you've forgotten, the XmlEditGrid control isn't part of the usual assortment of Web Matrix controls. This control is the one we downloaded from the Online Component Gallery in the "Connecting to the Online Component Gallery" section of Chapter 2. If you haven't downloaded this control already, you'll want to download it using the instructions in Chapter 2 before you begin working with this section of the chapter.TIP Don't get the idea that the Online Component Gallery is the only place to get new controls for your Web Matrix setup. The online community has worked hard to put together an impressive list of controls that you can use with Web Matrix. In some cases, the controls aren't well documented, but they're normally based on existing (documented) controls and consequently easy to figure out. See the Control Gallery at http://www.asp.net/Default.aspx?tabindex=2&tabid=30 for details.The XmlEditGrid control is unique in that it treats correctly formatted XML files as database input. Of course, the key phrase is "correctly formatted"-the XML file must use a format that lends itself to display within a grid. The SampleData.XML file we discussed earlier does have the proper format for display in the XmlEditGrid, so we'll use it in this example. Other files in the Sample XML Data folder will also work, but this file is particularly easy to understand.You can use the XmlDataGrid as you would any other grid for database work. The XmlDataGrid includes features that help you edit, delete, and add records to the XML file using an interface that looks just like a standard database grid. Figure 7-3 shows an example of the XmlDataGrid loaded with the movie database (found in Movie.XML) we looked at earlier in the chapter.Figure 7-3. Use the XmlDataGrid to view XML files as you would any database file.Setting the XmlEditGrid up for use is easy. Begin by adding the control to the form. If you want to use this control for XML files, you must supply the name of a file in the XmlFile property. The XmlEditGrid can also use a data source employing techniques similar to the ones we examined in Chapter 5. In short, the XmlEditGrid is a data grid with some extra features.I found that some configuration tasks are easier if you open the properties dialog box shown in Figure 7-4 by clicking the Property Pages icon in the Properties window. The dialog box groups some task elements, such as formatting, in an easy to understand manner. You can still use the Properties windows, but the dialog box presents fewer problems. The default setup for this control uses almost no formatting at all, making it difficult to see some features, such as the currently selected record, so you'll definitely want to perform some configuration.Figure 7-4. Using this dialog box to perform tasks such as formatting makes the job easier.Depending on how you configure the XmlEditGrid, it will automatically provide basic editing functionality for XML files (I didn't test the database capability because we have other controls to use for that purpose). You can edit, delete, and add records to your XML file database. The XmlEditGrid provides an edit icon in the leftmost column (looks like a pencil). Click this icon the first time, and the XmlEditGrid will select the row for editing-click it the second time, and the changes appear in the file and the control deselects the record. Immediately to the right of this icon is the delete icon (looks like an X). The control doesn't provide any warning about deleting a record-it simply performs the act on the selected row when clicked. The add feature appears as the Add new item link at the bottom of the grid. You can override most of the default actions performed by the XmlEditGrid by creating event handlers for them.You'll find that there are a couple of idiosyncrasies with this control. The first is that when you install the control from the Web, it will usually register itself in the GAC on your local machine. (If you don't register it in the GAC, make sure you create a \bin folder for each application and place the control there.) Unfortunately, when you move the application to your server for testing, it will fail. You'll find the control located in the \Program Files\Microsoft ASP.NET Web Matrix\v0.5.464\Components folder of your machine. Copy the control to the server and use GACUtil to register it. The control location doesn't matter, as long as you properly register the control-CLR will find it.The second problem is a little harder to figure out. Figure 7-5 shows the display you'll see when you get the application running the first time. Notice that all of the icons are missing. This problem doesn't prevent the application from working, but it's an annoying problem from an appearance perspective.Figure 7-5. Fixing this error can prove bothersome until you know how.The way to fix this problem is to use the View >Source command in Internet Explorer to view the source code that the control creates. You'll notice that every entry has this bit of code.<img src='/aspnet_client/Swarren_XmlEditGrid/1_0_0_0/edit.gif'The only problem is that you don't have the required folder on your server, nor did the control tell you where to find the image on your local machine. You can find the errant icons in the \Program Files\ASP.NET\Client Files\Swarren_XmlEditGrid\1_0_0_0 folder of your local hard drive.It seems that the installation program assumes that you'll use the local Web server for all testing. Simply create an \aspnet_client\Swarren_XmlEditGrid\1_0_0_0 folder in the root directory of your IIS installation, and copy the GIF files to it. The icons will mysteriously reappear in your application. Of course, this opens the door for customization. If you don't particularly like the icons that the XmlEditGrid uses, replace the GIF files in this folder with icons that you do like-just make sure you use the correct names.The XmlEditGrid control performs a lot of the work for you right out of the package. Even so, I needed to add two pieces of code to the example. The first displays the name of the XML file, while the second allows for sorting. The one feature that doesn't appear to work correctly right out of the box is sorting.
Listing 7-1 shows how to add both features to your application.Listing 7-1. Code for Sorting Grid and Display Filenamevoid Page_Load(Object sender, EventArgs e){// Display the name of the XML file.Label1.Text = "Data Source Is: " + XmlEditGrid1.XmlFile;}void XmlEditGrid1_SortCommand(Object source, DataGridSortCommandEventArgs e){// Define a sort order for the XmlEditGrid.Response.SetCookie(new HttpCookie("SortOrder", e.SortExpression));// Tell the user about the sort order.Label2.Text = "The sort order is: " + e.SortExpression;}As you can see, the application adds the filename during the page loading process, which means you could allow editing of more than one XML file using the same page without losing the user. The XmlEditGrid1_SortCommand() uses the same technique the DataGrid control uses for sorting-you send a cookie back to the server with the required sort order. This method also adds text to a second label that shows the sort order to the user. The XmlEditGrid is unsorted when you first display the data. Figure 7-6 shows the final output of this example using the SampleData.XML file.Figure 7-6. Creating output with any XML file that contains data in the correct format is easy with XmlEditGrid.
Removing Custom Controls from Your ProjectThere's a small, but important, change that occurs when you add a custom control to your project-one that you downloaded from the Internet or otherwise added to your toolbox. Web Matrix automatically adds a <%@ Register> tag to your code. As we saw in Chapter 6, this tag registers the control for you and makes it possible for ASP.NET to load it. Consequently, adding the tag is a good service for Web Matrix to provide.Unfortunately, as shown in the following illustration, this tag is only visible when you view the All tab of the editing window. For example, I added the XmlDataGrid control to this project. You can see the <%@ Register> tag immediately below the <%@ Page> tag.When you remove a custom control from the Design tab, the <%@ Register> tag remains in place. Unless you happen to look at the All tab, you won't see the tag and could try to deploy your application with the <%@ Register> tag in place. If you don't include the requisite DLL with your application, it won't run even if the code is correct. Removing the tag will fix the problem.