[pmwiki-users] Pagelists, adjunct data pages & variable sort orders

picp pmwiki at ben-amotz.com
Tue Oct 17 11:40:14 CDT 2006


Patrick R. Michaud <pmichaud <at> pobox.com> writes:
> Thinking about it a bit more, it's clear that page variables
> are (or should be) the general pmwiki hook for doing custom things
> with attributes and properties of pages, in whatever form.

Hmmm...

What if ZAP/FASTData created a custom page variable to save its form generated
data (instead of saving it to separate pages in separate groups)?  

The data would be hidden and protected from ordinary page edits because it would
not be part of the "text=" line of the file, it would be in its own separate
"zapdata=" line.

The other page variables/attributes/properties, such as name, title,
description, could be shared and available to both the page content (text=) and
the data (zapdata=) because they would all be saved in the same file
(Group.PageName).

Storing zapdata outside of text would require additional support for page text
variables and editing of zapdata.

For page text variable support, PmWiki would have to look beyond the text= line.
 Could PmWiki provide a hook for recipes by using an array for referencing the
locations to be searched for page text variable definitions so that the current
location (text=) could be expanded by a recipe to include another attribute
field (zapdata=)?

As for editing the contents zapdata, I'm not sure whether that is actually
required.  Doesn't zap data use forms to add (and overwrite) its data?  Does zap
data also require that data pages be directly editable using PmWiki's text edit
action and text box?

If direct editing is important in this case would it make sense to provide an
option that allows a PmWiki edit action to use the content of text= as the
default, but optionally allow direct editing of the content of the zapdata=
line.  Which would raise the issue of whether to allow any page variable to be
separately edited.  For example, the description page variable could be directly
edited in a separate screen, instead of using the description directive.  Such
an option could benefit authors by affording them greater greater control over
the content of their page variables and Pm (or PmWiki core development) by
either freeing up some markup (page variable directives) or reducing the demands
on such markup to support anything beyond some basic level of page variable
definitions.

I really should stop here to avoid overload, but I'll just note that opening up
page variables to direct editing and parsing for page text variables can have
broader application in addressing issues that arise when we start spinning off
pages into separate related pages with a common basename (SlicedBread and
SlicedBread-Talk) and could have implications for how we approach comments. 

Pico





More information about the pmwiki-users mailing list