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

[The Editor]

Hey Pico, these are some great ideas.  Added a few thoughts and
answered a few questons...

On 10/17/06, picp <pmwiki at ben-amotz.com> wrote:
> 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)?

This would actually be very easy to do (on my side) as I already have
ZAPdata and ZAPlog (comments) set up as separate variables, and I use
one function to save them.  The question is, would searching,
textvars, pagelists, etc., all be available?

> 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.

Good!  Much better than trying to hide data on a page with (:if false:)

> 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).

Oh this sounds wonderful...  Especially being able to work with
titles, better, but everything actually.  I suppose ZAP could easily
be setup to tap into any of the fields desired.

> 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=)?

If this could be done, the editing wouldn't be a problem.  The way
data is edited, is data is retrieved, used to prepopulate fields, and
then override with any changes.  I have to use hidden fields to
preserve/protect fields I don't want to change.

> 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?

Yes, for question one.  No for question two.  ZAP parses the data
itself, so a person need not have edit, or even read permissions to
display data. Of course with the new native support for text
variables, I'm not sure what the advantage of ZAP's data read process
is. Other than shorthand.

> 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.

Actually ZAP is being redesigned under the code with a full range of
permissions for different kinds of actions.  (right now levels are
login, read, forms, upload, and admin (emails and file management
mostly).  This could easily be added under the admin options.

> 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.

Often when things get opened up, many things become not only better,
but simpler.  I think that is the case here.  Great ideas Pico!  Can
it be done Pm?

Cheers,
Caveman