[pmwiki-users] Hiearchical Groups Proposal.
jo at durchholz.org
Wed Oct 18 09:35:33 CDT 2006
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).
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:
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.
More information about the pmwiki-users