[pmwiki-users] Pagelist problems (pretty advanced)

The Editor editor at fast.st
Mon Oct 16 15:32:50 CDT 2006

On 10/16/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Mon, Oct 16, 2006 at 02:27:17PM -0400, Crisses wrote:
> >
> > >>(:if name Category.Period-* :)
> > >>(:pagelist link=Category.{$Name} group=Simile fmt=#periodcatlist
> > >>list=normal order=$:Year,$:Work,$:WAuthor :)
> > >>(:ifend:)
> > >
> > >Do you really want to be searching on the Simile group,
> > >as opposed to the Data-Simile group?  In other words, which
> > >group contains the pages with the "Year: ..." markups?
> >
> > No -- the Category group links are not on the Data-Simile pages.  The
> > Category links are on the Simile/Page itself.  i.e. link=Category.X
> > will be on Simile.PageName  -- If I switch this to Data-Simile, the
> > category pages are all blank.

Not sure I follow all this, so if I ask an off the wall question, just
disregard.  But is there an  possibility the basename variable could
somehow be used with Categories?  If so you could perhaps but the
catagory links on the Data pages but get them returned to the Simile
page? Alternately, what about putting a redirect on all the datapages?
 When you say they show up blank, are you saying the datapage shows up
blank? The category pages contain the links right, correct?

> > The pagelists should be taking care of all the data lookups.
> Uh oh, I think we can't get there from here.
> > So I need to grab the variables from Data-PageName for the order:
> >
> > (:pagelist link=Category.{$Name} group=Simile fmt=#periodcatlist
> > list=normal order={Data-{$BaseName}$:Year},{Data-{$BaseName}$:Work},
> > {Data-{$BaseName}$:WAuthor} :)
> Alas, this absolutely doesn't do what you're hoping it will do.
> There's not a way to pass an argument to order= that says "I want
> to sort based on values in pages other than the ones in the
> pagelist".

Same caveat as above, as I'm not following this fully, but got
interested based on the reference to FAST Data below...  To do this
you would either need the data values on the simile pages, or the
category links on the data pages.  No other way around this, right?
And if you used the latter, you could sort, and return Simile pages
using basename.  Right?  Wouldn't that work?

> In the above, the {...$:Year} and other variable substitutions
> occur _before_ the (:pagelist:) directive is processed.
> So, what's happening is that {$BaseName} is receiving the basename
> of the current page (as opposed to the basename of each page
> in the pagelist), and the order= arguments are the year, work,
> and wauthor values from whatever Data- page corresponds to the
> current page (i.e., the one displaying the pagelist).
> I fear this is a huge design complication of FASTData,
> in that it creates relationships between pages (e.g., Data-Simile/XYZ
> and Simile/XYZ) that (:pagelist:) knows nothing about.  Personally,
> I would've chosen to have the data go directly into the Simile
> pages, rather than factoring them out to a different group.
> Then everything would work much more naturally.

I had been toying with allowing the option of saving data in the same
page as the form and could do it with fairly minor revisions if you
recommend it.  My idea was to save the data and log section under a
(:if false:) header so that it would not show in the page, but still
be accessible to reading.  The only other thing I would need to do is
rewrite how the page is saved and read so it preserves any existing
markup in the page itself. To enable this, you just set the ZAPprefix
to "", rather than "Data-".  Actually it's basically already setup to
allow this, as I was planning to introduce it somewhere in the current
beta version.

BUT, I had just about decided against this, because in the log files
(comments) I often use conditionals, esp if I want to allow editing of
a comment by an admin or by the original author, etc.  Those
conditionals would mess up the (:if false:) conditional and show up on
the page in a messed up way.  (*unless* I chose to disable the markup,
and perhaps reenable them in a ZAPlog--but that messes up the protect
feature which keeps PmWiki markup from being introduced...)

So, it could be done--and I'd just leave the responsibility of using
that capability to the admin.  Perhaps Pm, you could clarify the pro's
of offering it.  That is, is there no other way to do what Crisses
wants?  Or any other situations where it would be vital?  I can handle
the code, I've just been hesitant to add it, as it introduces various
other complications--and ZAP is already getting pretty, shall we say,
flexible.  Maybe though, the way I should look at it is ZAP forms
should give admins every option possible, depending on their


More information about the pmwiki-users mailing list