[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