[pmwiki-users] Pagelist to list $:ptv>1993

[Peter Bowers]

On Thu, Oct 29, 2009 at 6:49 PM, ABClf <languefrancaise at gmail.com> wrote:
> Hello the list,
> My question today is about using range, or > or < with pagelist.
> My purpose is to list pages where $:Date is >=1993

I don't think this capability is built into pmwiki.  Here are some
possible alternatives...

(a) Use the if="date 1993-01.. $:Date-01"

I'm not sure if appending that -01is necessary or whether it will even
work -- just an idea

(b) Create your own conditional operator

if="greateq $:Date 1993"

See http://www.pmwiki.org/wiki/Cookbook/ConditionalMarkupSamples --
I've taken a shot at modifying the "equal" condition below (no
promises -- just a quick shot):

$Conditions['greateq'] = 'GreaterEqualArgs($condparm) == 0';
function GreaterEqualArgs($arg) {
$arg = ParseArgs($arg); return (@$arg[''][0] >= @$arg[''][1]);
}

[1]

(c) It's not ideal, but you can use character classes to make your
wildcards a lot easier to maintain

(:pagelist trail=Argot.BibliographieDesDictionnaires fmt=#title
$:Date=199[3-9],20[0-9][0-9]:)

Hope that helps!  (Note that these are just ideas to point you in
possible directions - no testing whatsoever..)

-Peter


[1] This idea could be very easily generalized to allow for any binary
numerical comparison...

if="numcomp $:Date >= 1993"

$Conditions['numcomp'] = 'NumericCompareArgs($condparm) == 0';
function NumericCompareArgs($arg) {
   $arg = ParseArgs($arg);
   # Would be nice to check $arg[''][1] here using in_array() and give
an error message
   # Would be nice to check for existence and numericalness of [0] and
[2] and error nicely
   switch (@$arg[''][1]) {
      case '>': return (@$arg[''][0] > @$arg[''][2])
      case '>=': return (@$arg[''][0] >= @$arg[''][2])
      case '<': return (@$arg[''][0] < @$arg[''][2])
      case '<=': return (@$arg[''][0] <= @$arg[''][2])
      case '!=': return (@$arg[''][0] != @$arg[''][2])
      default: return (@$arg[''][0] == @$arg[''][2]);
   }
}

Of course it could be done much more simply with eval() but then you
have all kinds of security implications and you end up with even more
code to deal with that...

No testing whatsoever on any of this code.  You're on your own for that...