[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]

XML document design: a detailed look

I will talk about the problems that XML and XSLT have allowed Acxiom to solve, with detailed examples, during the session, and the next section will show you all the techniques we use.

First, let’s look at a separate example of a design problem, using something closer to home: the COVERAGE.APP that ships with VFP. It will give you a chance to think about those important definitions I mentioned earlier: what XML document structures will you accept, and provide, as messages? The design possibilities are almost unlimited – certainly less structured than relational database design – so how do you choose?

The COVERAGE.APP provides an example with some unusual aspects, but, at the same time, it’s is an obvious showcase example for VFP-using-XML.

The problem to solve

You may recall that, starting in VFP 6, the Coverage log offers a “stack column”, which is not represented in the standard COVERAGE.APP interface or analyzed by the VFP 6 Coverage engine. This omission exists for two reasons:

· The stack information was added into the Coverage text log relatively late in the VFP 6 development cycle.

· The shipping Coverage models Profiling and Coverage aspects of the log that do not lend themselves to the visual representation using the same interface as the nested stack levels of programs. They are different dimensions of the same log data

In previous conferences, I have demonstrated ways to include the stack information in the Coverage interface using a separate dialog, since you can add any additional dialogs you want into the standard UI (see figure 5 below). If you were interested in stack levels and not concerning with Coverage and Profiling, you could also build a special Coverage interface on top of the Coverage engine, with this type of dialog as your main display.

As you can probably tell looking at Figure 5, I used a grid to represent the stack information in the Coverage log. Underneath the grid, of course, was a VFP cursor. In the cursor, I added columns as the stack levels grew deeper. With rows representing code components, such as classes and programs, and stack levels represented as columns, each new stack level could be represented in the grid. You simply scrolled far enough to the right or left. I built some extra features, such as tooltips on a cell level, to overlay more information into this interface.

This was convenient – because cursors are natural to us in VFP – but it wasn’t an entirely apt metaphor. Nested levels of programs were awkward to display using this flat structure of rows and columns. Although the grid allowed me to represent the stack, it placed the visual emphasis on the wrong elements. Tracking all program elements that happened to fall in stack level 6, for example, was easy, paging through the grid, but didn’t present meaningful information. I couldn’t turn the row-and-column structure sideways, making stack levels rows and program elements columns, because I’d easily run out of available columns in the cursor.

Attempting to use a relational structure was even worse. Stack levels to code components is actually a many-to-many relationship. This relationship can be modeled relationally, but it does not “feel” natural – nor does such a relationship display “naturally” in a VFP interface.

A tree view might have been more apt as a metaphor, to represent the stack. But it takes one heck of a treeview to display the variety of calls and program elements in any Coverage log. It would have been slow to create, and memory-intensive. What’s more, this representation would not allow me to represent the various statistical elements of the Coverage log entry properly, without a kludge. The display would have been attractive and evoke a stack, visually, but would not have lent itself to statistical analysis.

Figure 5, Coverage VFP6 interface displays stack levels in a special dialog, along with other types of display for different purposes.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ]