[pmwiki-users] Pagelists, adjunct data pages & variable sort orders
editor at fast.st
Tue Oct 17 14:55:04 CDT 2006
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.
More information about the pmwiki-users