XMod To XMod Pro - Part II:

In Part I of this series, I discussed how to convert your XMod data entry form to an XMod Pro form. In this part I'll take the GridView template that was used and convert it for use in XMod Pro.

One of the benefits of XMod is that it does a lot of stuff for you under-the-covers. XMod Pro does a lot of stuff for you too, but it allows you to get closer to your data and closer to the HTML used to display that data so you can have much greater control over the entire solution. It's true with data entry forms and it's true when it comes time to display that data.

The XMod GridView Template

Let's start with our XMod GridView template:

Basically, we've defined a column – one for each field in our form. Each column has been given some text to display in its header and we've included an <xmod:field> tag in each column that displays the data for that column.

XMod Pro doesn't have a GridView template type. So what do we do?  We build it ourselves. It may sound daunting, but you'll discover it's quite a simple process. Before we start, though, I am assuming you've read through the <xmod:template> topic in the XMod Pro help file. I won't have the room to explain all the tags and their features.

The XMod Pro Template

Templates in XMod Pro are defined using the <xmod:template> tag and its child tags. The purpose of this tag is to encapsulate all the settings and content your template needs to display and function. If you're familiar with XMod's Repeater template type, you'll recognize the similarities.

There are four possible components to each template:

• <HeaderTemplate>: (Optional) This is rendered once in the template, before anything else in the template. It doesn't contain data.
• <ItemTemplate>: (Required) This is rendered once for each record unless an Alternating template is defined, in which case, it renders for every odd record – the 1st, 3rd, 5th, etc. It is data-bound, so while the format/layout of the template will remain the same, the actual content (data from the database) will change.
• <AlternatingItemTemplate>: (Optional) If defined, this template will render for every even record in the dataset – 2nd, 4th, 6th, etc. Like the Item Template, it is data-bound. It allows you to provide a more visually appealing layout when needed. For instance, you can provide a different background color than the item template. The result will be a striped layout.
• <FooterTemplate>: (Optional) This is rendered once in the template, after all the data-bound rows (Item and Alt. Item templates). It doesn't contain data.

To create our grid, all we need to do is use the HTML <table> tag. We add the opening, non-repeating portions of the tag to the <HeaderTemplate>. This includes the opening <table> tag, an opening <tbody> tag, a single table row (<tr> </tr>), and multiple table header (<th> </th>) tags – one for each column - that contain the header text. We could use use table cell (<td> </td>) tags but the table header tags are better for accessibility.

Next, we add the repeating portions of our table. Instead of <xmod:field> tags, XMod Pro uses field tokens. The principal is the same. Instead of <xmod:field name="LaptopModel" /> we simply type [[LaptopModel]] – a much simpler, cleaner syntax. So, for the repeating portion of the table, we will only use the <ItemTemplate> tag to keep things simple. The <ItemTemplate> tag will contain the repeating portion of our table – one table row (<tr> </tr>) that contains table cells (<td> </td>) for each column:

Finally, we need to close out the table in the <FooterTemplate>. This part is quite simple, just a closing </tbody> and </table> tag.

When put together, the template will look like this (notice we've wrapped everything in <xmod:template> </xmod:template> tags):

Retrieving the Data

There's one final thing we need to do to bind our table to our data – Add a <ListDataSource> tag. This is similar to the <SubmitCommand> you saw in Part I. The <ListDataSource> is responsible for retrieving the data to show in our list view. So, we'll use a SELECT command and select each of our needed fields from the LaptopInventory table. Ensure that the column names in your <ListDataSource> match the field tokens in your template exactly. These are case-sensitive: LaptopModel is not the same as Laptopmodel.

All that remains to be done is put our <ListDataSource> into our template:

There you have the first stage of conversion. Next we'll need to enable the ability to Add records, Edit records, and Delete them. Stay tuned for Part III.