As promised yesterday here's an example of a Flex app that does some basic data reporting on a set of backend documents.

For the sake of demonstration I've invented a Staff Skills Database. Each document records a member of staff and what programming skills they have.

In the Notes client the "person" document look like this:

In reality the form is more likely to be web-based but I want to keep this simple for the sake of the Flex demo.

All very straight forward, no?

The screengrab below is of a standard Notes view showing the staff documents. The first column is categorised by the multi-value Skills field and shows documents with more than one value in more than one category. The last column of the view reports how many people have that skill. Still, all very simple and standard Notes stuff.

This is all very well, but how do we represent this on the web and, more specifically, in Flex.

Categories On The Web

There are various way of representing Notes categorised views on the web. They all seem to try and mimic the Notes view paradigm though and I've never really understood why. The web isn't Notes, so why try and fool users in to thinking it is!?

In Flex the data consumed is, most likely, going to be XML. In XML a document with a multi-value field would be represented like so:

<document id="JHOT-7WBJWG">
        <name>Aaliyah Andrews</name>
        <age>26</age>
        <gender>Male</gender>
        <dept>Sales</dept>
        <categories>
                <cat>HTML / DHTML / XML</cat>
                <cat>Perl/CGI</cat>
                <cat>SQL</cat>
                <cat>Java Developer</cat>
        </categories>
</document>

Using this data structure it's possible with Flex to "categorise" the documents without having to load the same document over and over again for each category, which seems a silly way of doing it.

Traditionally, if you have 10 categories and 100 documents, which happen to be in all ten categories then you'd have to load 1,000 rows of data.

Why not just load all documents once and process the data client side? That's what I've made Flex do. Here's the example (click to go to the demo):

Let's take a closer look:

The left hand pane is a list of all the skills and includes a count of the number of staff with each. Selecting any one skill filter the grid (view) to only show staff members with those skills.

Much better than a drop-down box to select a category and have it fetch a new set of documents each time, no?

Although I've put the title "By Category" above the list I don't think I'd do that in a real world app. That's just for us. In reality I'd avoid the use of the word category completely.

Other Features

Some other cool features of the demo:

• Notice you can filter the grid using the search field above it. This is in combination with the skill selection from the left. So if you have a skill selected the search operates on that subset of document.
• You can "group" the view using the checkbox top-right. This is more normally what we'd call categories.
• Below the view is a tally of the number of documents currently being shown.
• Bottom right of the view is a button to copy the currently displayed documents to the clipboard in CSV format.

It's worth looking at the XML consumed by the Flex app. Notice that almost everything is controlled from there -- what columns to add to the view and in what order, which of the columns can be "grouped" and which are to highlight matches from the search field. The XML also defines the whole set of categories/skills as well as storing all of the documents for the demo. All this in one hit!

Drawbacks

Hopefully, once fully loaded, you'll be amazed at how quick the filtering works. Both when selecting a skill and/or using the search field. That's because it's not going back to the server each time.

To be able to avoid a server round-trip each time you need to be confident that the dataset is never going to grow to the point where it's not practical to load it all in one go. In this example we're loading 2500 staff members and the load is ~600kb.

If your dataset is likely to grow without bounds then the approach falters a little. It can still work, but would need to go the server each time you select a category or use the search field.

Summary

The concept of the staff skills might be a little bogus, but hopefully it gets the idea across? There are always different ways of doing something that has always been done the same way in the past.

The code for the Flex app and Notes database is coming tomorrow/later on, along with a bit of a challenge for any XPage lovers.

Update: Download

You can download the Notes database here. The Flex source is in the Zip files in the File Resources section.