You mean something like mix:referenceable? (aka
Session.getNodeByUUID())? ;-)
/Janne
On Sep 1, 2009, at 01:07 , Murray Altheim wrote:
Janne Jalkanen wrote:
The first determination would be to decide whether this data should
be stored as a Property of a WikiPage or as a generic binary blob
under some special page...
Easiest would be to simply define a special page and then store it
as a Binary blob there. This would mirror the current storage in
workDir.
JSPWiki stores currently the WikiPages as JCR Node /pages/<space
name>/<wikiname>. We could store the data under /
wiki:PageViewPlugin/, perhaps? But that means that you need to
access the JCR store directly (using the JSR-170 API), and it might
not be import/exportable. THe other possibility is to define a /
pages/<space name>/System:PageViewPlugin or something and store it
there, but then it becomes tied to a particular wikispace
(=something else than a static var is needed to store the data).
Opinions?
Another approach is modularising various functionality via linked web
services, which we've been doing for about a year now. This might not
be appropriate for this instance but I thought to mention it.
We've been using REST-style web services for a number of things, where
the ties between a page and some kind of related metadata is weaker
than might be for what we normally consider page-level metadata, or
in instances where we don't want to "corrupt" the page record with
content not properly part of the page itself (such as user comments).
We're doing this for a prototype chat service and for a network status
feature (where our engineers alter status information on a separate
web service site and it shows up on the wiki using a plugin), but it
occurs to me there might be other appropriate uses.
This kind of modularity has been valuable and has kept our wiki
content
cleaner, with the links always via wiki page name. One of the projects
in the plans is a persistent identifier (permalink/tinyurl) web
service,
where the canonical identifier for a wiki page would be a persistent
identifier (PID) rather than the wiki page name (which could change).
This would require the addition of the PID to the wiki page metadata
and a simple resolver from PID to wiki page URL (which could be done
via a fielded Lucene search or a hashtable). The PID then becomes the
common link between web service and wiki page, which makes more sense
than using a mutable wiki page name. With the move to a Priha/JSR-170
style backend this might be easier than with the 2.8.2 code base.
Some ideas anyway...
Murray
...........................................................................
Murray Altheim <murray09 at altheim dot com>
=== = =
http://www.altheim.com/murray/ =
= ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
= = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
