The Joy of Flex

This is Buzzword’s style inspector. It’s a Tree control combined with a DataGrid that lets developers view and modify the underlying document model as it’s being modified by the editor. It’s an example of a high-level debugging tool that we built into our application early on. I’m not knocking the Flex debugger, far from it. But it’s only one tool in the debugging toolbox, and you need more.

Way back at the beginning of Buzzword’s development, when we were building the original document model, the first thing we did was lay out lines of text into paragraphs and pages. As soon as that was up and running, we built what I think of as the first real feature in Buzzword: bold, italic, and underlined text.

The underlying data structure of Buzzword’s document model is an object tree. The root of the tree is the document, which contains sections, which contain paragraphs, which contain runs, which contain text itself. At every level of the tree, objects can have styles. So, for example, a paragraph object can have styles like spaceBefore, spaceAfter, and lineSpacing. And a run can have styles like bold, italic, and underline. Styles are represented as a list of name-value pairs: bold=true, italic=false, and so on. Edits to the text and styles of of a document are represented, therefore, as a combination of tree operations like adding and deleting nodes, and modifying the style values of the objects in the tree. (Note: I’m simplifying the design for discussion here, but these are the basics.)

It’s hard to believe in retrospect, but there was a time before the Bold, Italic, and Underline buttons in Buzzword. Before we had those buttons, or any other UI for that matter, we needed to be able to inspect and modify style values in the object tree, so that we could verify that the style system was working properly, develop more features, and so on. We thought that, before we actually built the real UI for anything else, we ought to have a general-purpose style inspector that would let developers easily view and modify styles. It didn’t have to be intuitive and familiar like the Bold button. What was important was that it had to be general purpose, so that it could be used to view and modify any style it was faced with.

When I was figuring out how to build the style inspector, I quickly came upon some components in the Flex framework that were just about idea for the job: Tree and DataGrid. The Tree component was great for displaying a tree structure like our object tree, and the DataGrid was great for viewing and editing name-value pairs like styles. Hook them together and we’ve got our style inspector.

One detail worth mentioning is that the Tree component has some pretty great superpowers underneath its red suit. If you’ve used a Tree component at all, you’ve probably hooked it up to a dataSource like an XML object, which is very easy to do. But Tree also has the ability to display data from any arbitrary tree structure. To do this, you need to implement an interface called ITreeDataDescriptor. This interface has two subsets of methods you can implement: one for viewing nodes, and one for editing them. If all you want to do is view the tree, you just have to implement getData(), isBranch(), hasChildren(), and getChildren(). These methods take a node as a parameter, and let you write the bits of code that actually traverse the tree. You set the Tree’s dataDescriptor to an instance of your ITreeDataDescriptor implementation, and you set the Tree’s dataProvider to the root node of your tree, and you’re in business.

As the screen shot alludes, there is also a layout inspector that allows developers to examine the underlying layout model that represents how a document is laid out into lines and pages. In fact, just about any application of size is going to end up with an object tree, or several. Building an inspector out of a Tree and a DataGrid is a great way to climb up the debugging “food chain” and make your whole development team more productive.

Update: typos corrected.

Technorati Tags: Flex, Flex Builder, Debugging