2020/06/12/Ferreteria

Codeblog 2024/11/14 untangling setup calls - mostly just notes to myself 2023/06/04 config classes 2023/05/01 DataPorts redesign 2022/07/21 FutilityCloud process design 2022/08/14 Windows joke I wrote in the late 1900s (on TootCat) 2022/07/21 render-dispatch rubberduckery 2022/07/20 comments on The Home Computer Generation 2022/07/18 layout-event rubberducking 2022/06/24 event-object as output container: the consequences 2022/06/23 event-object as output container: the revision 2022/05/30 more data-class rubberducking 2022/05/20 rubberducking about data classes 2022/01/15 standard CV data format 2021/12/17 The Great Data-Class Restacking 2021/11/25 PHP documentation gripe 2021/11/24 things you can't do in PHP 2021/11/23 PortBank refactoring part 2 2021/11/22 PortBank refactoring part 1 2021/11/08 data objects refactoring 2021/11/05 notes for event-system burndown 2021/07/31 a code mystery 2021/05/31 new PHP wishlist item: first keyword 2021/05/28 a kluge using abstract methods 2021/03/21 PHP wishlist 2020/12/04 (notes) 2020/10/30 (notes) 2020/10/29 (notes) 2020/10/28 (notes) 2020/10/27 (notes: Dovecot on cloud5) 2020/08/29 MediaWiki SpecialPages 2020/08/25 The Plex API 2020/06/12 Ferreteria: thoughts on the Wikcess/flex-data system 2020/04/23 Ferreteria: quick notes on a design issue 2020/04/22 Ferreteria: some thoughts on apps vs. frameworks 2020/02/10 job application (yes, I actually sent this in)

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)