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

[The Editor]

On 10/17/06, Pico <pmwiki at ben-amotz.com> wrote:
> Patrick R. Michaud <pmichaud <at> pobox.com> writes:
> >
> > 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=

This thought occurred to me too.  With the new Update feature ZAP
saves diffs for both data and logs (comments).  Which is nice.  But
the trade-offs might be worth it...

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

Are you saying there's already away to store a ZAPdata string or a
ZAPlog string to a page attribute?  Maybe you could give a hint how to
do that.  Of course without being able to search/pagelist these, it
might not be worth much...

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

You came up with a nice solution for Crisses, but it seemed quite
complex to me.  If I could just set a parameter in a pagelist or
template to some other page attribute than text, that seems far
easier.  Oh, and PageVars also.

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

Yes, it seems to me, this might be a good move for the future before
PmWiki explodes to much further!  It would give you a lot of power for
as yet undreamt up uses.  I like it.  Pico's example (deleted below)
was a good one.  I could list others that quickly occur to me, beside
ZAP.  It's pretty exciting--as long as we don't lose functionality in
the change...  Pagelists, Search, TextVars, etc.

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

I agree.  Just one history file.

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

Yes, things could get worse!  : )

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

Awesome.

Cheers,
Caveman