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

Pico pmwiki at ben-amotz.com
Tue Oct 17 14:03:19 CDT 2006


Patrick R. Michaud <pmichaud <at> pobox.com> writes:

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

Thanks.

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

Yes, I recognized that and I don't see a need to have history support 
attributes other than text=
 
> > 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.
>

How would we use it for other attributes?  When I invoke the attr action 
I only see the password fields.  Is there a attribute edit form that we 
would have to modify?
 
> > 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.
> 

Ok, well I guess the basename idea may have started with draft.php 
before being exapnded more recently to take into account the practices
of PageName-Talk and perhaps Data-Group.PageName.  In each of these 
contexts, we are maintaining separate pages, with separate histories and
separate attributes.  We recognize that these pages are related and so 
we look to the basename variable to provide the link.  But we are still
maintaining separate sets of attributes when we might be better served 
if those attributes could be shared.  

Lets start with examples of pages where we want to distinguish between 
certain content that we want to protect (the basic details of my recipe 
for SlicedBread that keeps getting messed up spam and novice posters) 
and other content that we want to keep open and accessible 
(SlicedBread-Talk).  Instead of creating two separate pages, SlicedBread 
and SlicedBread-Talk, I could use a page attribute to contain my recipe, 
that is, the entire contents of my original SlicedBread page, and simply 
include it in my page, either directly in the page itself, or through 
the GroupHeader.  As a quick hack test, I created a page that just 
contains a {$Description} call and opened the underlying file in a 
separate text editor, together with another file (PmWiki.PmWiki).  
I copied the entire text= line from PmWiki.PmWiki to saved it to a
"description=" line in the new file. 

When I opened the new file in PmWiki, it displayed a fully rendered 
version of the markup that I had pasted over from the text= line in
PmWiki.PmWiki.  I don't think I could ever have pulled that off using 
the (:description:) directive.  (And using an include would miss the 
point of the excercise, which is that rendered output does not depend 
on the existence of a second page, in this case, the PmWiki.PmWiki page).

If that basic approach was anticipated and supported, it could be used to
protect basic page content while allowing unrestricted editing of 
additional content (stored in the text= line), which could be used in 
place of maintaining separate pages, with separate attributes and names 
that share only a basename.  The content of SlicedBread-Talk, or
SlicedBread-Draft, or both, could be saved in the basename SlicedBread page,
with various page attributes shared.

Returning to your earier comment about histories, the content of text= 
could continue to be the only attribute that has its history of changes 
tracked, which would leave the other attributes as fixed final or published 
text that could be changed, but not reverted, unless its contents had 
previously been within the text= line.  

The fact that I am talking about drafts and publishing should not be taken 
to mean that I think the core draft feature is difficient or needs fixing.  
I was amazed when I first started to understand what happens when you use 
draft and floored when I recently opened up the draft.php file and saw the
sparse simplicity used to achieve the results.

Instead, what I am focusing on is what appears to be a growing trend of 
spinning off a single page into multiple separate pages and, in the process,
losing the benefit of shared attributes.

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

Thanks for your time, attention and input.

Pico






More information about the pmwiki-users mailing list