[pmwiki-users] Hiearchical Groups Proposal.

[Joachim Durchholz]

The Editor schrieb:
> Jo said:
>> Ideally, metadata would be pages, possibly with a special marker in the
>> page name so PmWiki knows that they don't get meta-metadata.
> 
> Separate pages for groupheaders and footers (which should NOT be
> inheritable to subgroups). But no to passwords, etc, which should be
> inheritable (ie: store in the page).

That's independent.

If group headers and footers are in separate pages, PmWiki would have to 
go up the hierarchy and scan for pages anyway.

Say, if the current page is named foo.bar.baz. The relevant attribute 
pages might be named foo.bar.baz.%Header, foo.bar.baz.%footer, and 
foo.bar.baz.%passwords. If these don't exist, PmWiki would have to look 
in foo.bar.%Header, foo.bar.%Footer, and foo.bar.%passwords, then 
foo.%Header, foo.%Footer, and foo.%passwords, and finally %Header, 
%Footer, and %passwords.

Now this would give us three directory scans:
   foo.bar.baz.%*
   foo.bar.%*
   foo.%*
   %*

That would make all of passwords and headers/footers inheritable, with 
no additional directory scanning overhead.
*And* it would keep the path open to additional kinds of metadata - 
again, with no additional directory scanning.

Additional overhead might be involved when processing the contents of 
the files - but that's always the same, regardless of where it's taken from.

On the plus side, it would be possible to split up the current files.

E.g. PmWiki could store the actual page text in a file, and all the 
other data (history and whatnot) in separate metadata files; that would 
make the PmWiki files far easier to read and process using external 
tools. It would also help with page displays - the page read code would 
be reduced to a simple filegetcontents(), instead of the current code 
that has to identify the text, try to stop reading at end-of-text, and 
convert line ends back to newline codes; this would simplify and 
slightly speed up the page read code.

Regards,
Jo