[pmwiki-users] Planning for 2.2.0

[Henrik Bechmann]

Patrick,

Remind me of the syntax for a page variable that will resolve for the 
browsing page? {$:Group}?{$.Group}? (As long as it is a simple change 
from the current, it shouldn't be that hard for admins to fix, as there 
aren't many Site. pages compared to the rest).

FWIW, an alternative syntax for page text variables might be {!TextVar}, 
in which case page variables resolved for the declaration page could be 
{$.PageVar}. The presentation of the logic could be PageVariables 
resolve globally by default in order to allow for assembly using generic 
components (unless qualified), and text variables resolve locally.

A component  that could be compatible with the {!TextVar} approach might 
be to introduce a (:scope local|global:) (:scopeend:) directive, which 
could apply to either/both page and text variables. That would provide 
the opportunity to assemble generic wikitext into pages so that text 
variables for example could apply to the including page rather than the 
included page by using (:scope global:) in the included page. This may 
be too tricky or expensive for the parsing engine of course.

BTW, getting back to {$PageCreatedBy}, I would argue that it should be 
added to be symmetrical with {$LastModifiedBy} (and {$PageCreationDate} 
to go with {$LastModified}).

- Henrik

Patrick R. Michaud wrote:
> On Fri, Sep 22, 2006 at 10:48:11AM -0500, Patrick R. Michaud wrote:
>   
>> On Thu, Sep 21, 2006 at 10:30:21PM -0500, Patrick R. Michaud wrote:
>>     
>>> 1.  Page links and page variables inside of included pages will
>>> become relative by default.  [...]
>>> In short, page variables and links that aren't fully qualified
>>> will be treated as relative to the page in which they are written.
>>> (Currently they use the page that is being browsed.)
>>>       
>> Okay, I've run into the first major obstacle with this -- namely,
>> the Site.PageActions page currently expects page variables
>> such as {$Name}, {$FullName}, {$Group}, etc., to be the
>> page being browsed as opposed to the page in which they are 
>> written (Site.PageActions).
>>
>> Changing this could be difficult on many sites that have customized
>> Site.PageActions, or that are using a skin that has its own view
>> of the Site.PageActions page.
>>     
>
> In thinking about it further, all of the solutions I can come
> up with this seem worse than the original problem.  So, I'm
> thinking that perhaps we just "bite the bullet" on this one
> and let chaos reign for a short period of time.  There shouldn't 
> be many pages that need to change, and the administrator will 
> always have the option of setting the transition flag that 
> restores the old behavior until they have a chance to migrate 
> everything into the new format.
>
> The only alternatives I see are:
>    - leave things they way they are now, which will continue
>      to confuse authors in the future, or
>    - leave the {$var} syntax alone, and come up with a new
>      page variable syntax.
>
> I'm not fond of either alternative.
>
> Pm
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>   

-- 

Henrik Bechmann
www.osscommons.ca
www.bechmannsoftware.com
Webmaster, www.dufferinpark.ca