I’ve run into a bit of a design delimna with Inklog. It’s not too difficult to understand and, in the end, it really doesn’t matter. However, I thought I’d get the opinion of other developers before proceeding.
In Inklog, all the items that the system can display are represented as objects (PHP Objects) within the code. However, the data is stored in a database, so the objects need to be flattened and then reinflated. The method I choose to use when flattening is this. One table holds the object’s shortname (unique to each parent), title, type, data, creation date, modification date, and format. This table has a parent field to represent what object contains this object. A second table holds the various properties of an object. Each object type requires certain things to be present within it. For instance, a BLOG object type requires a TEXT object type with a shortname of "content" to be contained within it.
This presents two problems. First of all, it is difficult to determine which objects were added by the owner and which objects are required elements of thier parents. I could place the required elements in another table, but that seems silly. I’d like a way to easily determine, however, which things were added by the owner, and which things are required by the parent object type. Another problem is that, rarely are both "data" and any of the other fields used. For instance, if we consider the above BLOG object. In the actual BLOG object, there is a title, a createdate, a modifydate, and a shortname. But the BLOG object doesn’t have any data of it’s own. Instead, it’s child named "content" has data. However, this child doesn’t really have a title, and, it’s createdate and/or modifydate are unimportant since the BLOG object that is its parent has that data already. Additionally, while this "content" child has a shortname (because everything has one), the object it isn’t meant to be directly accessed. This is easily determined by the object type (i.e. TEXT objects should never be directly accessed) but, without extensive processing, it isn’t easy to make that determination.
There are two options that I can think of to solve this issue. The first is quite simple. Remove the uniqueness requirement of shortnames within a parent and enforce said requirement in code instead of in the database. Then, for any object that is a required element of it’s parent, don’t give it a shortname and use the title field to name the object. With this model, any item without a short name is both not directly accessible, and is a required element of it’s parent. It sort of defeats of few of the design goals that I had for data integrity, but it works.
The second option is to place required elements in a table of their own with a parent field to denote their relationship. The biggest downside to this approach is that this means that any required element of an object type must be a "simple" object (like the "content" object above) and not a complex object (like the BLOG object above). One of the main differences between a simple object and a complex object would be that a simple object cannot contain other objects. This could end up limiting the functionality of certain object types that would like to require a complex object. I can’t think of any examples off-hand of where this would be needed, but Inklog is about being open, flexible, and extensible… so I’d rather not place that limitation on the system if I don’t have to.
I guess there is a third option. I could add a "required" field to the database that is set to TRUE whenever an object is a required child of its parent. This would denote that it is unable to be accessed directly and would also allow a simple SQL query to determine the list of owner added objects within another object.
So I ask of you, which method is better, or is there another option I have yet to think of?