[pmwiki-users] Properties

Patrick R. Michaud pmichaud at pobox.com
Mon Dec 12 14:18:40 CST 2005


On Mon, Dec 12, 2005 at 03:03:06PM -0500, Martin Fick wrote:
> > * Three properties are predefined by PmWiki as saved properties:  title, 
> >   keywords, and description.  Thus the (:title:), (:keywords:), and 
> >   (:description:) directives become shortcut markups for doing the 
> >   equivalent of (:property title="...":), (:property keywords="...":), 
> >   and (:property description="...":).
> 
> No big deal, but I guess this would mean we would have
> {$Title}, and {$$Title} being the same thing?

It might work out that way, it might not.  One difference may be that
a page has only one {$Title}, but if a property is allowed to
change over the lifetime of a page there could be multiple {$$Title}
values.

There are quite a few other issues I'm discovering -- for example,
getting

    (:property myprop=foo:) {$$myprop}
    (:property myprop=bar:) {$$myprop}

to work properly is going to be fairly tricky.

> > * Saved properties can be used as ordering criteria in pagelists,
> >   thus  (:pagelist order=myprop:) would order the list according to
> >   the "myprop" saved property setting.
> > 
> > * We may also be able to use saved properties as filters, thus
> >   (:pagelist myprop=something:) would return only those pages
> >   that have a "myprop" value with "something" in it.
> 
> Uhm, syntax might conflict with existing options: does
> (:pagelist trail=foo:)  look for the property foo in pages
> or does it take the pagelist from page foo?

I would suspect that only saved properties get to be filters,
so unless someone defines "trail" as a saved property, there's not
really an issue.

> Are there any toughts of making COOKIES, REQUEST vars etc.
> available as properties or variables?

Seems like it'd be fairly easy to do from a local config:

    $Properties = array_merge($Properties, $_REQUEST);

> > * The "custom variables" in Cookbook.PageListTemplates could become 
> >   "properties" of the current page in the list, thus
> > 
> >       {$$prevname}       - previous page in list
> >       {$$nextname}       - next page in list
> >       {$$pagecount}      - current page count
> >       {$$grouppagecount} - count of pages in current group
> >       {$$groupcount}     - number of groups
> 
> I get what you mean, but I think they would not actually be
> properties of the current page but of the current template.

Sorry, I meant "current page" in the same sense that PageListTemplate
currently has {$Curr} -- i.e., the current page in the list, not
the page being browsed.

> > * If we define a markup rule that treats markup lines of the form
> > 
> >       name: value
> > 
> >   as setting a property value (i.e., the same as (:property name="value":), 
> >   then capabilities such as PITS become almost trivial to implement, 
> >   including the ability to sort and filter based on properties in the 
> >   page markup.  
> >   ...
> 
> 
> Very neat, but I would fear that a lot of properties would
> be getting set unintentionally.  Within a page this would be
> no big deal, but it would make it hard to get good results
> from pagelists.

Not at all, since only those properties that are designated
as saved properties would be stored in the page file and available
for filters.  For that matter, the "name: value" markup can be
enabled only for saved properties.

Pm




More information about the pmwiki-users mailing list