ecently, I was working on the user interface for a tool to maintain an online catalog. Because the catalog featured so many products, it made sense to categorize them in some way. The catalog administrator would need the ability to delete and define new categories, nest categories within other categories, and generally manipulate both categories and products in a direct and intuitive fashion.
Hierarchical scenarios like this cry out for a hierarchical view of some kind. First, the mapping between data and its representation is usually trivial, because the TreeView control's object model is itself hierarchical. Second, the ability to expand a tree's nodes on an individual basis makes it easy to browse data at multiple levels and granularities simultaneously. Finally, dragging and dropping folders in a TreeView is a particularly simple and appealing way to manipulate complex hierarchies quickly.
After a few minutes I realized that the application I had in mind was Windows Explorer, and that I was about to rewrite it, with product categories in place of file folders and product items in place of the files themselves. I was even going to re-implement the accelerator shortcuts to create and delete folders and perform drag-and-drop operations. And I would probably find myself writing the same thing all over again if I later decided to code an interface to a relational database, a contacts management program, or even a tool to trace my genealogy.
This made no sense. What I needed was a generic way to bind a hierarchical data source to a TreeView control, in the same way that you can bind a database table to a data grid. But in this case I wanted to get all the creation, deletion, renaming, moving, and dragging-and-dropping of data elements "for free," regardless of the structural content of the data source in question.