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

[Patrick R. Michaud]

On Tue, Oct 17, 2006 at 04:40:14PM +0000, picp 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)?  

I think you mean "page attribute" here instead of "page variable".

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

It's a nice idea -- I'll think about it more.  But keep in mind that
as things are currently implemented, anything that is not stored in
the text= attribute doesn't get any history associated with it,
so it wouldn't be possible to restore values of previous edits to
the other attributes.  And I'm not sure I want to be maintaining
multiple history streams for a page, although we could perahps
see about doing that.

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

PmWiki _already_ has a facility for directly editing page attributes --
it's called ?action=attr.  It's just that nobody's really using it
yet for anything other than passwords.

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

I don't quite follow the broader application here, at least not
as I've been envisioning things.

I'm willing to look at ways that we can have page text variables
grab values from page attributes as well as by scanning the
text... but then perhaps we need to call them something other
than "page text variables" if we do that.  Perhaps at that point
they just become "page properties", and we say that page properties
can either be set via markup in the page's text or by special
attributes held in the page files and managed via ?action=attr
or by other recipes.

Pm