Quote:
Originally Posted by Ckorik
Right now they are storing the links between items somehow - because you can literally pull up a view of every link the item has to it within snippets. This is actually kind of a cool view btw.
The only difference here is they would need to create a new type of database object that holds a specific type of snippet that says 'if I exist then render me as the parent object' (yes this isn't trivial as it sounds - I'm not ignorant of that fact).
The 'shortcut' topic would be an actual node with a single generated snippet type with some kind of key to generate the callback to the topic - short sweet and works just like everything else in the database (the actual topic can even get it's own auto-generated random name that we never see) - the real work would be in the render engine when finding *that* kind of snippet/topic rendering the referenced topic.
No relationship issues would exist that don't already based on how they are doing things.
|
Yes, they would.
With each topic having only one container right now that relationship is simply an item in the record, probably. In order to allow for an unlimited number of containers, you have to create a separate table of nothing but topics and containers that has to be searched and joined to the main table every time you need to build the tree. And honestly it makes no sense to have a privileged container under that scheme, no matter where you find the name in the tree you should be able to open the topic directly.
I happen to agree that this is a desirable feature just that Rob is likely to have other opinions and this is why.