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

[Crisses]

Ok, I'm sitting here writing a long explanation on this to my  
client...but it occurs to me that I should address both the list and  
Patrick about this first.  Before I incur another 20 days of work  
only to find this feature is added next week.

We're working on having pages like PageName-Talk as an adjunct page  
to PageName.  PageName-Comments.  Data-Group.PageName or PageName- 
Data etc.

All these ways of having pages attached to each other, sharing data.

I put all the book/author information into Data-Group.PageName -- all  
the relevant page variables are there.  And everything works except  
the pagelist sort.  And works well.

Would it be a lot of trouble to fix the pagelist sorts?  Yes, says  
Patrick.  And that's ok, this is only about one wiki.

But what if I used these features for a shopping cart?  What if I  
used these features to sort forums?  A business directory?  I'm  
really seeing many instances where I want plain data in one place,  
where a user can't alter it, versus a page where the user can alter  
what it comes out looking like (formatting the data).  The data isn't  
ON the page in question, it's being pulled from somewhere else.  I  
have the simile data pulled in from the GroupHeader -- it doesn't  
live on the page.  I was thinking at first that users might edit the  
page to add comments.  I want the data separated completely from the  
body of the page, and not touchable by the user.

Now I have to take 20 steps back, and make invisible page data on the  
actual Simile.PageName -- not impossible, just terribly  
inconvenient.  Since I can have a Simile.PageName-Talk page, I  
suppose it's not really necessary to allow users to edit the Simile  
group pages.  That's fine.

But let's say I want to treat this a little like a forum -- I want  
all the last authors of the Simile. *-Talk pages, sorted, in a forum- 
styled pagelist, and I want it to return the Simile page (which in  
this theory has Simile.PageName-Talk included in the GroupFooter).

I can't do that sort, even if the Simile data is stored on the Simile  
pages....and while it's a little far fetched to do a sort like that  
for a simile-encyclopedia, it's not far-fetched if we're looking to  
have CMS-like abilities and want to sort *-Talk pages by their last  
modified time and return the PageName of the threads by latest comment.
order={{$FullName}-Talk}$LastMod,{$FullName}$LastMod

Would return pages commented on last OR created/modified last --  
assuming it doesn't have any comments yet.


I see a few ways this could be accomplished:

A setting that says "Share the variables from $BaseNamePatterns +  
$group on this page" -- happens when the page variables are read.   
This requires a loop be added to the portion of PmWiki where the  
variables are read from the page, and more than one page would have  
to be looped through to read variables.  This gets messy fast if  
there are multiple groups (say Data-Page and Page-Talk) and a pagelist!

Move ordering to the format (fmt) area of the output -- the pagelist  
stores the data in an array, passes the whole array of data to the  
output formatting committee, and order is part of the format. The  
formatting code already deals with other page variables as needed for  
formatting the actual output, so it could process the output in  
memory, then spit it out when done rather than spit it out line-per- 
line??  Frankly, from the authoring point of view the order seems to  
go hand-in-hand with the format of the pagelist to me... but on the  
programming end of pmwiki.php it goes with the pagelist logic.

A hack.  A total and complete hack.  I could probably make a hack if  
I had to.  Custom markup.  Whatever.  It would stink.  It would be  
messy. Slow. Complicated.  Not worth it.

And Patrick's answer:  Forget storing data in separate groups.  Store  
it on the page.


Thoughts?

Crisses
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20061016/d24c784e/attachment.html