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

[Crisses]

On Oct 16, 2006, at 7:26 PM, Patrick R. Michaud wrote:

>     order=yearauthorwork
>
> and have a custom function do whatever sort you wish, including
> grabbing page text variables from other related pages (where the
> function defines the relation).

function yearauthorwork() {

}

What data is passed to the function, if any? What format does the  
output need to be in?

>>    order={{$FullName}-Talk}$LastMod,{$FullName}$LastMod
>>
>>    Would return pages commented on last OR created/modified last  
>> -- assuming
>>    it doesn't have any comments yet.
>
> FWIW, I think that at some point we have to stop asking the PmWiki
> markup syntax to solve every conceivable problem, and just say
> "okay, this particular feature needs a custom PHP function to
> do its work".  I'm not necessarily saying that we've reached that
> point here, but for some things markup is a terribly inefficient way
> of getting to our results.

Oh, I don't believe in scope creep on this.  I just have a hard time  
saying "yes you can spit out pagelist groups based on arbitrary data"  
while also saying "but the groupings won't work as expected because  
you can't sort them".  The basepage format options have worked well,  
but I consider that either a missing feature or bug, because I try to  
group the output to eliminate dupes and it fails miserably due to the  
unsorted nature of the pagelist being handled.  If I can handle it in  
a pmwiki-hook ratified manner, great.  If I have to try to hack  
pmwiki without knowing the hooks, it's going to be *awful*.

>>    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.
>
> Not really.  Again, although everyone just loves pagelist  
> templates, they're
> not the way that the pagelist code was originally designed to work,  
> nor are
> they intended to be able to produce every conceivable output format.

I missed the whole evolution of pagelists -- or I was there but it  
was over my head at the time, and I didn't need it so I didn't grok  
it ;)  When I came back to it and finally needed it, I was pretty  
impressed by the whole "programming language" of it.

> The output of pagelist is *completely* controlled by the fmt=  
> option, and
> this can also be a custom function, instead of using a pagelist  
> template.
> In fact, in 2.0 all pagelist output formats were handled by custom
> functions, as pagelist templates weren't introduced into the core  
> until 2.1 .
> It has never been my intent to completely replace all pagelist output
> using pagelist templates.

Ok -- but are the hooks documented, because I might need to make a  
half-dozen to a dozen custom templates *winces*

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

The point at which I don't have a hook, it sure as heck IS a hack ;)   
And it would be very messy.  I was thinking about whether I should re- 
program the whole pagelist as a custom markup... calling all those  
pages "manually" and trying to get variables out of them would really  
be painful.

> Again, just so I'm not misunderstood -- I'm very much in favor of
> doing things that will make pagelist templates and (:pagelist:)
> arguments able to solve large classes of problems.  But I also
> want to avoid putting too much complexity into the system, and I
> do think there are times when markup is the wrong tool for the job
> at hand.

I know this and agree with it.  I'm hoping I don't need to back out  
of everything I've done and start from the data entry form onwards....

Crisses