[pmwiki-users] Wikipaths (was: PData support for pagelisting images)

Henrik Bechmann henrik.bechmann at sympatico.ca
Thu Sep 7 20:57:25 CDT 2006


> How does (:includefieldpage:) get the page data from pages in other
> wikis?
>   
In (:includefieldpage field=Newsletter September2006.SomeArticle:)

The code takes the field name "Newsletter" to find an intermap entry

Newsletter-Pages:        /newsletter/wiki/wiki.d/

And then uses code I shamelessly lifted from your (:include:) code to 
fetch the page text file and process the data. It by-passes any security 
in the process (including read restrictions), because my environment 
does not require read restrictions, just write restrictions.

It all works as long as

- people use (:includefieldpage:) -- not (:include:) -- for recursion 
(since includefieldpage is context independent), and

- intermap rather than relative entries (ie NOT Attach:) for image 
locations, and always intermap references for page links. eg:

* [[(Newsletter-Wiki:September2006.)Some Article]] for a link to the 
above article (whether inside the Newsletter field or not), where 
Newsletter-Wiki: is found in farmmap.txt as Newsletter-Wiki:        
/newsletter/wiki/wiki.php/, or

* Newsletter-Photos:SomePhoto.jpg for a photo, where Newsletter-Photos 
is a repository found in farmmap.txt as Newsletter-Photos:        
/newsletter/photos/)

When these conventions are used (I have found little resistance on the 
part of authors), then relative addresses are sidestepped, and any page 
in any wiki field can be included in any other throughout the farm, with 
successful presentation of images and recursive includes. This allows 
for massive re-use of pages in a variety of contexts. In turn it leads 
to innovative presentation and insight... It totally works for me.

See http://www.pmwiki.org/wiki/Cookbook/IncludeFieldPage (slightly older 
version).

I suppose the ideal solution to all this would be to have a field-based 
context switching mechanism (defaulting to the current field), with some 
way of assembling data from a variety of fields, and some core and 
pervasive way of referencing a non-default field (like 
Field::Group.Page). But that sounds like a pretty major design leap, and 
if it's not what you intended for fields, then it obviously shouldn't be 
done.

I know, I know, I've just basically cheated to add a third layer of 
categories to PmWiki (although the physical/administrative isolation is 
also useful), but as I've said before, I cheat a lot<grin>. And I 
actually don't mind the explicit repository references all over the 
place: tends to maintain some modicum of discipline and order...

... but if I've forked in a direction where PmWiki ISN'T going, I'd 
rather know sooner than later...

These enhancements you're talking about sound pretty awesome (I'm 
basically a database application person...).

- Henrik

-- 

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





More information about the pmwiki-users mailing list