From Woozle Writes Code
Jump to navigation Jump to search


My default plan (which I even started reflexively coding once or twice) was to have some overarching system by which each node could be assigned a code-class for handling it. There would be a central registry of classes which would be built at start-up, each class having a short-name which would be referenced by a twig in the node record, so that you could pull up any arbitrary node and it would be displayed in a way that was appropriate to its purpose.

The more I thought about it, though, the less I was able to come up with an actual use-case for when you'd want to display an arbitrary node with a specific-purpose view. This became even more apparent when I got back to thinking about node security, where different views of the same data might have different security rules -- e.g. a piece of information in the node might be invisible yet influence how the data was displayed in a low-privilege view (e.g. some users get to see additional info) without even revealing that twig's existence to the user, while in a high-privilege view the information would be plainly displayed and possibly editable.

From that, it seems clear that each node-display class needs to (a) define its own security rules and (b) be able to recognize whether it can display a given node or not -- or, more to the point, be capable of pulling up a list of nodes that are within its purview.

And now that we're talking about different views of single nodes, it starts to make sense to talk about having multiple views of node-collections. For example:

  • Filesystem view -- every node exists in exactly one place in a hierarchy
  • Topic view
    • any node may appear more than once, or never (though there should generally be a way to list all unassigned nodes)
    • organization could be hierarchical (like a filesystem) or not (like categories in MediaWiki), or flat (like hashtags)
  • Gallery view -- display all nodes that support some kind of thumbnail rendering (with an option to list those that don't)

The immediate upshot, in any case, is that there will be:

  • a lowest-level default view which will observe view and edit permits across all nodes without any purpose-specific context, and more specific views will override that as needed.
  • each class will decide for itself what indicator to use as far as finer-grained security (e.g. a special "!rights" twig)