[pmwiki-users] hierarchical groups, revisited
Dr Fred C
drfredc at drfredc.com
Thu May 25 11:40:54 CDT 2006
IMHO, the complexity and handling of hierarchical groups all depends
upon the foundational construct and then procedures one uses traverse
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.
In wiki terms, the USER "animal" file block substructure would be broken
into and stored as separate files:
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
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.
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
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
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
More information about the pmwiki-users