incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murray Altheim <murra...@altheim.com>
Subject Re: [jira] Created: (JSPWIKI-120) Separate rendering engine from core
Date Sat, 05 Jan 2008 11:25:50 GMT
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

Mime
View raw message