Data Hierarchies

Every object in Inphusion exists somewhere in a hierarchy. The framework handles moves, updates and so on within the hierarchy as transparently as possible for the application developer.

Each class reveals on request a list of possible child objects classes. Requests to create a child object that is not of an allowed class (or to move a portion of the tree, such that the class of the highest node of that portion would not be on the allowed list of the new parent node) will be rejected. This mechanism can be used to enforce hierarchies such as project -> subproject -> job -> task. It would also allow, if desired, any entity from across the system to be "attached" to any other - for example, a "comment" object could probably be attached to anything else.

This means that the Inphusion Data Hierarchy component provides the structure of the tree; what objects are added to the tree depends on the classes of object which are added. A basic building block of this strategy is an agnostic "container" class - think it like a filesystem directory. In fact, a filesystem is a very good way to think about how the Hierarchy side of Inphusion works. You start with a root, which has several child directories / folders. Each folder can contain n files, each of a different type - perhaps a .doc, a .txt and a .xls file. Inphusion - like the Operating System's "registered application" concept - "knows" which application to use to open the files.

That's where the analogy breaks down a little though. In most O/S's a file is the basic unit (ignoring streams for now). Inphusion allows infinite nesting of objects, following rules defined by each class, which tells the system what classes of object are valid children. This makes it much more flexible than a purely filesystem approach. Otherwise, this would all be pointless - we should just use the webserver as a front controller serving native objects!

Note to PN Reviewers:

The current implementation of data hierarchies in Inphusion is the vC Hierarchies system as explained to me by Russ Brown. I am currently refactoring this to use a variant of Vadim Tropashko's nested intervals theorem. However for now, simply refer to PN CodeDocs to see how this stuff works - it's effectively a materialised path heirarchy with a couple of clever tricks.