[pmwiki-users] PData support for pagelisting images

Martin Fick mogulguy at yahoo.com
Thu Sep 7 15:22:33 CDT 2006

--- "Patrick R. Michaud" <pmichaud at pobox.com> wrote:
> I've been wondering if this goes the wrong way, and
> how much it would hurt existing sites to change 
> things around at this point (possibly as a 2.2.0 
> release, if we do it).

Yes, I have always felt that way also (I think 
it was even mentioned in an email a long time 
ago), despite the fact that I currently make 
heavy use of the current behavior.  The 
alternative just seems more "correct."

> So, how much pain would we cause by switching this
> around now?

Big, but manageable pain mostly incurred by 
"advanced authors" who will most likely at
least understand the ramifications well.  
Those who wouldn't follow as easily are not
likely to be affected anyway.

> If we fixed it so that {$Name} and [[link]] were
> always treated as being relative to the page in 
> which they are written, we could introduce another 
> form to refer to the currently browsed page.  
> Something like {==$Name}, or perhaps {*$Name}
> or {.$Name}.  

I like the dot.

> 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]]?

> (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?)

> 1.  (:include:)
> I don't know of many cases where people are relying
> on the fact that links inside of an (:include:)d 
> page are relative to the including page.  In this 
> case links like [[name]] would need to be rewritten 
> as [[{.$Group}/name]], or an option given to include

> that says "relative links are based on
> the including page".

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.  But the easy 
part about this is that it tends to be in 
infrastructure type pages, so as you mention
below, the number of pages that would need to be 
changed is rather limited, GroupHeaders, Footers, 

Of Course, that does mean that entire site 
structures would be broken in the mean time.  
But at least it does not mean searching through
a bunch of heavily content oriented pages and 
editing them.

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

> Usually the issue with (:include:) is the other way
> around; people
> expect [[name]] to be relative to the included page,
> and when it
> doesn't work they have to go in and add the group
> name to become
> [[group/name]].  So, switching wouldn't hurt these
> cases.

I agree.

> 2.  GroupHeader/GroupFooter
> Group headers and footers are by definition in the
> same group
> as the browsed page, so [[links]] aren't a problem. 
> However, it would
> be odd if {$Name} and {$Title} referred to the
> GroupHeader's name
> and title instead of those of the browsed page.
> However, if we add a base= option to (:include:)
> that says things
> are relative to the including page, then we can
> avoid the problem.
> 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.  If you make the
don't hold back, go all the way.

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.

> 3.  Pagelist templates
> Pagelist templates that have {$Name} or {$Group} in
> them
> (without any leading '<', '=', or '>') would have to
> be updated
> to use {.$Name} or {.$Group} instead.

Small changes with big obvious effects...

> None of the core pagelist templates make any use of
> page variables
> such as {$Name} or {$Group}, all of them strictly
> use things
> like {<$Name} and {=$Group}.  These would continue
> to 

> 4.  <!--wiki:...--> directives, sidebars.

> These are a lot like (:includes:), in that most 
> authors expect the [[links]] to be relative to the 
> sidebar and not to the currently browsed group.  
> So, this matches #1 above.  I don't know how many 
> sidebars are making use of things like {$Group}, 
> {$Name}, and {$Title} -- they would have to be 
> changed to {.$Group}, {.$Name}, and {.$Title}, 
> or the sidebar told to use the currently browsed 
> page as its base.

Small changes with big obvious effects...

> Still, the number of sidebars is a pretty small 
> proportion of pages, and it's easy to find them, 
> so perhaps this switch wouldn't be too bad.

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!!

> It's the one I'm most certain would be easier 
> for new authors to grasp, but also the one that 
> could cause the most problems for existing sites.

...and current recipes and the docs.

> Any comments or thoughts on this idea?  Too 
> radical for existing sites to swallow, or 
> should I pursue it and see what happens?

Radical, but nice.  

Speaking of radical, did you have any thoughts 
about my proposal for what I am now thinking 
of as "wikipaths", the idea of defining a more 
generalized lookup grammar instead of just 
defining {$:tex}? 

ie.:  {{page$section(index)...}} 

where section migh be: *,#,!,:,::[,(:directive:) 
and more.

I have begun coding a small recipe, I'm sure 
you could code one much quicker though.  Is 
it something that you think would be too 
complicated?  If so, to design or for authors
to understand?


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the pmwiki-users mailing list