[pmwiki-devel] objectizing pagelist?

[Martin Fick]

--- "Patrick R. Michaud" <pmichaud at pobox.com> wrote:
 
> There's not any generic code for handling (:template
> first ... :) (:template each ...:) yet, but I've
been
> considering factoring it out into a common set of 
> subroutines.  But even if we do that, there's still 
> the issue of figuring out how to handle expressions
> like {<$...}, {=$...}, and {>$...} for things that
> aren't really page variables.  Currently that's a 
> very _pagelist_specific thing because '<', '=', and 
> '>' get replaced by pagenames and transate into
calls 
> to PageVar() .

I want to give you a related example real use 
case that I have found pagelists not quite 
flexible enough to handle even when applied to 
actual pagelists.  This example might give you 
some ideas as to what someone might want to 
achieve with any refactoring that you do.

The Content recipe creates things that look a
little bit like pagevariables but they have
a slightly different syntax, they begin with a
/ after the dollar, for ex:  {$/abctab}.  Since
I use the Content recipe with the Music recipe
it has come up that it would be nice to make
a pagelist that lists all the pages in some 
group and to provide a link to the page next 
to a link to the midi content of that page.  
So ideally a template line for a pagelist like 
this might look something like this:

* {=$Fullname}] - [Midi -> {=$/..midi}]

But since the pseudo page variable is not a real
page variable I don't see a good place to hook
this translation into the current templating 
mechanism.  Instead an author would have to write
something like:

* {=$Fullname}] - [Midi -> {{=$Fullname}$/..midi}]

The only flexible thing I can think of is to 
create another rule engine for templates.  Recipes
could then register rules that get applied during
templating.  These rules would also have to be
more advanced than normal markup rules since they
would have to take a pointer/reference to 
iteration specific page data to be able to make 
"= > <" substitutions.  This is probably way more
complex than what you want to do, but if you can 
keep the use case in mind when refactoring things 
you will probably come up with something better 
than what I have hinted at here.

Thanks,

-Martin


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com