This is a lot easier to explain now that code is available. In Inklog, each all data items are Nodes. However, in order to extend the functionality of what a "node" is, this basic, generic, node is expected to be extended. In fact, the default actions and methods within a generic node return error messages stating that this object needs to be extended to function properly. When an object is extended (like a page node) it gains additional properties and methods (which are data objects). And that's where the problem lies. There are three ways to do this.
1) The first method is to inflate all of the properties when the node is inflated. This requires a database hit for each property and additional memory consumption to store that data. This seems especially wasteful when, for instance, the user is trying to access the "description" of a 100MB image. There is no point in loading the image data from the database and no point in storing it in memory since it's never going to be used. The benefit to this method is that the object is real and fully inflated when it is called. It makes accessing those objects incredibly simple because they already exist and function just like a normal object. The downside is that a lot of useless information might be retrieved simply because a node was touched only to obtain one small piece of information.
2) The second method is to inflate the properties of a node on demand. Instead of accessing $this->property, a call would be made like so: $prop = $this->getproperty('foo'); The "foo" property would then be loaded and could be accessed normally. Since, in many cases, the theme/template will be the only part of the system that knows which properties will be used and which ones will not, this code will most likely appear in the templates, which looks cluttered and is difficult to understand. The benefit to this method is that the properties are only inflated upon demand. The downside is the additional clutter in the templates.
3) The final method is to obtain a list of the available properties and create empty property objects for each one. Inside of the property is an "active" flag. When a property object is accessed, its "active" flag will be checked. If the property is not "active" then the data will be retrieved then, that single property will be inflated, and the "active" flag will be set so the object knows that future accesses don't need to retrieve the data. The benefit of this method is that the properties are only loaded on demand (like the benefit of option 2) and yet are still "real" objects (like the benefit of option 1) that are simple to access even in templates. So this is the best of both worlds, but there is a new downside. Because these data objects now have to have some way of retrieving their own data, they will require access to the NodeFactory (which requires the DataDataStore) from within themselves. This makes the Object more complicated, with more dependencies.
I think option 3 sounds the best. I just hate to introduce layers of tight binding and complication that don't need to be there.
Advice? Comments? Suggestions?
