[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