[pmwiki-users] hierarchical groups, revisited

[Dr Fred C]

IMHO, the complexity and handling of hierarchical groups all depends 
upon the  foundational construct and then procedures one uses traverse 
the construct. 

About 26 years ago (pre-internet), I worked on a USER 
programming/language system (Universal Structured Enduser Resource) that 
in many ways has a  similar foundation to the pmwiki system.  While I've 
never dove into the sort of data structures of pmwiki, the USER system 
had at it's core a pointer based hierarchical data structure with a wide 
variety of data processes to handle that data.  

The hierarchical structure allowed for very flexible data and powerful 
data file structures.   A file "animal", might have the following data 
blocks in it.
 
*animal
**canine
***beagle
***poodle
****Curls
****Puffball
**bird
***raptor
****eagle
****hawk 

In wiki terms, the USER "animal" file block substructure would be broken 
into and stored as separate files:

animal
animal.canine
animal.canine.poodle 
animal.canine.beagle
animal.bird.raptor
.etc.

The way the USER system typically worked, was when the file animal was 
loaded, it was scanned for any subblock structure. (Yes, USER used 
*<blockname> to identify block names and boundaries).   In wiki terms, a 
hierarchical wiki file structure described above would eliminate need 
for a block scanning process, just read the wiki.d directory and create 
the appropriate data tree.  It also should be noted, there are 
advantages and disadvantages to either structure, with reasonable 
workarounds possible for both to achieve the similar goals.   FTSOA, 
assume we're dealing with the hierarchical wiki file structure noted 
above that has a pointer data tree to search around.

  A call from eagle (animal.bird.raptor.eagle) to animal.canine should 
first search up the pointer tree to see if it could find animal, then 
look down for canine.  It wouldn't look locally for animal, not find 
that, create animal.bird.raptor.eagle.animal, then (mistakenly) look for 
canine in animal.bird.raptor.eagle.animal, not find that and create 
animal.bird.raptor.eagle.animal.canine.  Search up the data tree before 
looking locally.  The first item on the upward search is the name of the 
local group 'eagle'. 

  A call from beagle to canine, would search up find canine and open 
canine.  It woudn't look in beagle and not finding canine, open 
beagle.canine.  A call for animal.canine from beagle would end up at the 
same canine page, but require first finding animal, then canine.  

  Also call from within canine to canine would search "up" to find 
canine, and not search the canine local list, not find canine and then 
start up canine.canine. 

  A call from eagle for Curls would end up with some sort of exception 
handling choice to be made.  Should one search to the tree top (animal) 
and if not finding Curls should it continue globally searching for Curls 
(finding animal.canine.poodle.Curls), or return to search eagle's local 
list and search for Curls, and not finding that, start up a local Curls 
handling process (create a new Curls link). 

  The USER default was if Curls wasn't found searching up the pointer 
tree, then one would look locally, and not finding that, initiate the 
eagle.Curls handling process (in typical wiki terms, create a 
"eagle.Curls" new page link).

  However, the USER language also included various specific data 
search/call modes where a call from eagle for Curls could look globally 
for Curls and find animal.canine.poodle.Curls.  If multiple Curls pages 
were found, menu options would appear...

  Like the typical wiki, USER exception handling forgiving and not like 
the typical computer languages and OSs which might blurt out some blue 
screen abort message.  

  It should be added that a properly organized flexible hierarchical 
data structure also allows for a variety of additional very powerful 
features to be developed. 

  For example, the USER system allowed for various 'gosub' calls to  
blocks (files) of data.   Where the typical wiki (and internet) link is 
a one way 'goto' link,  the hierarchical structure of the USER system 
allowed for 'gosub' calls to a remote structure that upon 'normal' 
leaving that structure, the user would return to the calling location. 

 Put into wiki terms, one of the typical uses for this hierarchical 
power might be in educational programs to allow for "reviewing" 
something with a link of something like  [[review: animal.canine.poodle 
|  Learn about Poodles ]].  If the link "Learn about Poodles" were 
clicked, the user would go to the animal.canine.poodle file and any 
local poodle group blocks to learn about poodles.  When the user was 
done learning about poodles, they would automatically return to where 
the "review" call was made, to continue whatever they were doing. 

  Yes, this allows for different options than the typical open ended 
internet structure where one must be disciplined enough to return after 
learning about poodles, instead of getting side tracked chasing down 
more info about the cute animal.human.girl walking the poodle.  Go 
figure... 

  Hence the S for Structured in  USER (Universal Structure Enduser 
Resource).   The USER structure creates all sorts of possible powerful 
programming and educational variants to typical internet surfing which 
astute programmers might readily recognize.  Sure, some additional 
exception handling is required to prevent such things as recursive traps 
that enduser's WILL accidently create. Like calling [[review: eagles]], 
from within eagles...   Been there, done that, it wasn't that tough.

Also, it should also be noted there were processes in the USER system to 
easily handle changing or inserting new layers into the data structure.

For example, in a USER file, if one changed the name of the data block 
bird to avian, when done editing, it would rescan to have all of the 
underlying bird data structures appropriately realigned under avian.

Additionally, in a USER file, adding coldblooded and warmblooded to the 
animal data structure required adding a * to each appropriate subblock. 

*animal
**coldblooded
***frog
**wamblooded
***canine
****beagle
****poodle
*****Curls
*****Puffball
***bird
****raptor
*****eagle
*****hawk 

For large USER files, a simple search "(linebreak)**" and replace with 
"(linebreak)***" typically worked great, but it was obviously a specific 
editor based feature.

The wiki version would necessitate creating and moving file names around 
a bit...

animal.warmblooded.bird  etc
animal.warmblooded.canine  etc.
animal.coldblooded  etc.

This file handling in wiki is not trivial programming, but also not 
impossible. It's also something that intuitively many user's find 
'wanting' in wikis.  They name a page as dufis, and then want to change 
it to dufus, but it's a hassle...   Or create dufus, dufus.big then find 
they want to create fools with substructure fools.dufus and 
fools.dufus.big.  Etc...

Again, all doable, been there done that.   Not trivial, but not 
unreachable and possible to do incrementally.

  Anyway, in summary, I've never really understood the complexity issue 
preventing more complex hierarchical structures to pmwiki.  But then my 
foundational perspective is from a (been there done that) system that 
from the get go had reasonably powerful built in data handling 
structures allowing for these sorts of additional complexities.  We also 
were doing everything locally, not on the internet.  All I know, good 
hierarchical handling is readily achievable if one starts out with a 
reasonable big picture of where one is going with such code enhancements 
while giving due consideration to the additional power (and problems) 
one is creating in the process. 

Also, as a side note, the USER system's intended target group of users 
were school teachers.  Those we tested it with seemed to understand it 
quite easily at their level, very similar to how easily most end users 
edit wikis.  Like pmwiki, those with programming background readily 
created all sorts of other (pre-internet) things.  Like PMwiki, the USER 
system had a level and niche for users of most every level of expertise.

What happened to the USER system? --- well, while I've a background in 
computer programming, I'm also a dentist.  I hurt my hand in the early 
80s and dove into programming for a couple years while my hand 
recovered.  When it recovered in the mid 80s, I returned to dentistry 
and the USER system languished... 

As a disclaimer, I've no idea how easily structure of php or pmwiki 
might allow for these sort of data handling processes.  It's been a 
quite a while since I've dove into code and swam around a bit... 

Hopefully, my perspective on having developed and worked on such a 
system will help those swimming around the pmwiki pool of php code to 
envision the possibilities, complexities, and solutions of how to get 
from here to there. 

-- 
Always, Dr Fred Chittenden