Janne,
I've recently had a need to parse WikiPages absent much else but
the wiki text content itself (I'm mostly interested in capturing
the output of some custom plugins). Apart from creating a dummy
implementation of a WebAuthorizer (called a PassThruAuthorizer),
I haven't needed to create a ton of code to do this; it was just
a bit trickier than I'd thought at first. Earlier today I spent
some time removing most of the dependencies on the external
application, such that at this point it is fairly independent,
just needing a dummy 'wiki' directory for some prefs files and
miscellany.
It's not standalone but could probably be a fixer-upper for
somebody in need. This was really set up for use with my
XNodeProvider but would work with minor modifications with a
normal FileSystemProvider (actually, just commenting out a
section would do that).
The WikiProcessor class provides four primary methods:
/* either obtains a cached one, or creates a WikiEngine */
public WikiEngine getWikiEngine( String appname )
/* parses content to a WikiDocument */
public WikiDocument parse(
String appname, String pagename, String pagedata )
/* parses content to a WikiDocument */
public WikiDocument parse(
WikiEngine engine, String pagename, String pagedata )
/* transforms a WikiDocument to a DOM Document */
public Document transformWikiDocument( WikiDocument wdoc )
At this point I've got roughly:
WikiProcessor: a wrapper utility class that instantiates a
WikiEngine and makes the parser available
PassThruAuthorizer: implements WebAuthorizer
WikiPageHarvester: heavily tied to my application, but might
provide a model on how an individual page gets
processed to capture filter and plugin output.
"wiki" directory: contains a minimal set of files, WEB-INF
directory, etc. (more likely useful as a sample)
I'm willing to distribute this as it might provide some guidance
on those trying to do the same thing. The code would be completely
unsupported as I simply don't have time for the next few months to
help people get up and running, though I would answer questions as
time permits. It's not very much code really and does include some
documentation.
If this makes sense, how would you think this best packaged up? I
could try to polish it up as a part of JSPWiki but at this point
it's probably more suited as a sampler.
Murray
Janne Jalkanen (JIRA) wrote:
Separate rendering engine from core
-----------------------------------
Key: JSPWIKI-120
URL: https://issues.apache.org/jira/browse/JSPWIKI-120
Project: JSPWiki
Issue Type: New Feature
Components: Core & storage
Reporter: Janne Jalkanen
Quite a few people have shown up recently on the mailing list and have
expressed a wish to separate the rendering engine from the core itself, so that
they wouldn't need so much baggage with the engine.
Unfortunately, this is quite difficult, as the rendering engine does rely on
quite a few bits from the WikiEngine instance, for example URL generation and
checking whether a page/attachment exists or not, as well as settings.
However, these things could be enumerated and isolated to a RenderingContext
interface. Then, anyone who would like to get their own engine would need to
implement this interface.
It may mean that WikiEngine and WikiContext might need to become interfaces as
well. However, that might not be such a bad thing, as it would give a more
stable developer API. Then we would have a three-layered architecture, where
one layer (WikiEngine) takes care of static stuff, WikiContext contains
per-request data, and RenderingContext provides the bits and pieces which are
part of HTML generation.
At any rate, this requires more thinking. Probably not going to happen before
3.0 anyway.
...........................................................................
Murray Altheim <murray07 at altheim.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
