[pmwiki-users] PData support for pagelisting images

[Patrick R. Michaud]

On Thu, Sep 07, 2006 at 01:22:33PM -0700, Martin Fick wrote:
> > Then, an author who really wants to refer to the
> > name and pages of the including page would write
> > 
> >    My name is {.$Name}, and I can be found
> > [[{.$Group}/here]].
> > 
> > to get the name and group of the currently browsed
> > page.
> 
> 
> Then, how about allowing [[./here]] or even
> better, maybe [[/here]] and [[.here]]?

I'd prefer not to, at this point.  Various hierarchical group
proposals are playing with other meanings of leading dots and
slashes, and I don't want to close that possibility for 
a rarely-used shortcut.  [[{.$Group}/here]] isn't that onerous
for the few times it'll be used (and it's also more explicit).

> > (Of course, we would provide an option that lets existing sites 
> > continue with the existing behavior for include, but
> 
> Very important since we would want to make people
> able to get updates without having to migrate 
> their site until they were ready.  Maybe some 
> variable could be set in a Group config page to 
> turn it on/off for that group?  (I don't know if 
> that even makes sense, would it be on/off for 
> included pages in that group or including pages?)

Group config pages apply only when the currently browsed
page is in the group.  Settings in a group config has no effect
when a page is accessed from another group (which is why group
configs cannot be used to set passwords).

> > 1.  (:include:)
>
> The case where it is commonly used for me is with 
> the 'virtual' group concept such as the Category
> group and things like the SideBar.  

[[!Category]] is already fully qualified, so it's
not an issue.  Entries in Group.SideBar tend to be
seen only in the current group anyway, so that's pretty
safe.  (How often does a page include a sidebar page from
another group?)  The links in Site.SideBar tend to have to
be fully qualified anyway.  The main places it would cause
issues in in things like:

    [[recent changes]] 
        --> [[{.$Group}/recent changes]]

    [[{$FullName}?action=edit | Edit page]] 
        --> [[{.FullName}?action=edit | Edit page]]

> Small changes with big obvious effects will
> probably get fixed easily since they won't 
> go unnoticed.

Good observation.

> > If we define $GroupHeaderFmt as
> > 
> >     $GroupHeaderFmt='(:include GroupHeader
> > base={.$FullName}:)(:nl:)';
> > 
> > then all of the links and page variables in the
> > GroupHeader would be
> > evaluated in the context of the currently browsed
> > page, and {$Name}
> > and {$Title} would work as we expect.
> 
> This sounds like a nice migration option, but I would
> not want it to be the default.  

I would, because I think an author's natural inclination
is to think that {$Name} in a GroupHeader refers to the
name of the currently browsed page, and not "GroupHeader".
Most people don't realize that GroupHeader is implemented
by using (:include:).  :-)

> I don't think that it is uncommon for a GroupHeader 
> (or footer, or SideBar) in one group to borrow from 
> a GroupHeader (...) from another Group by including 
> it, in which case the same issues still exist.

Only if the borrowed page makes use of {$var} or [[link]].
Not common, I don't think.

> Not bad, but this reminds me that many recipes
> would also need to be updated though. This might
> affect new users quite a bit if the recipes they
> use are broken.  I don't mean so much recipe 
> scripts (alhtough they may break too), but 
> recipes that have sample wiki markups in them,
> i.e all the docs!!

I'm not sure there's a lot of docs that have {$var}
markup in them that depends on it being absolute as
opposed to relative.  Some skin configuration pages 
might, though.

Pm