[pmwiki-users] smarter PageStore::ls() parameters?

Patrick R. Michaud pmichaud at pobox.com
Mon Oct 16 14:47:08 CDT 2006


On Mon, Oct 16, 2006 at 10:54:22AM -0700, Martin Fick wrote:
> > ----- Original Message ----
> > From: Patrick R. Michaud <pmichaud at pobox.com>
> > Subject: Re: [pmwiki-users] smarter PageStore::ls() parameters?
> > 
> > The current plan is to add an $options parameter to PageStore::ls(),
> > or (for compatibility reasons) to have a separate PageStore::select() 
> > method that takes this argument.  The $options parameter would
> > contain the things specified in the pagelist command, and the
> > PageStore may be able to use that to optimize the resulting query.
> 
> If you are going to add a Select() to the pagestore it would be
> nice if it took other kinds of search parameters and were sturctured
> something like this:
> 
> Select($namepats, $attpats)
> 
> where $namepats is equivalent to what the current $pats is for ls() and
> the $attpats is an array indexed by attribute which contains an array
> of patterns to match for that specific page attribute (which could
> include the page text).  This seems particularly useful if things are
> going to be stored in a db.

Either (1) you're saying exactly what I said -- i.e., the pagelist options
would be passed to the ls()/select() method, (2) you're greatly
oversimplifying things, or (3) I'm totally misunderstanding what you're
suggesting.

Assuming you mean "page attribute" in the way that I use the 
term -- i.e., a key/value pair that is stored in the individual 
page files -- then this doesn't seem to be at all helpful.  Very few 
of the arguments that we give to (:pagelist:) have an exact or meaningful
correspondence directly to a page attribute.  In fact, with the possible
exception of text= , all of the ones that would have such a mapping
are already being handled by the present system.

Pm




More information about the pmwiki-users mailing list