Hi, I've been using an embedded copy of JSPWiki within my project Ceryle since roughly 2004. I've tracked JSPWiki from about 2.0.52 to 2.8.x — running within Ceryle — which has Jetty built in. The deployment was relatively painless; I wrote a 'WikiUtils' class and an events handler so that when JSPWiki fired up the supporting application was informed and modified the wiki configuration depending on the application's location and settings.

When I upgraded to Jetty 6 the wiki was suddenly operating in a different JVM than Jetty and I lost a great deal of integrated functionality. I've since posted several messages to Jetty mailing lists asking if anyone knew how to force an embedded Jetty to run in the same JVM as the parent application, but after more than a year there's still no answer. So much for the free online Jetty support...

I've just posted my CeryleWiki, which of course is running on JSPWiki.

I'd been looking at alternative Java-based wiki as I'm trying to find a way to do metadata and other forms of data mining off of the wiki pages, essentially to be able to grab DOM-like content off of the pages, or via page metadata. I've started up a pages on WikiMetadataAPI, MultilingualWiki, WikiInternationalizationAPI and DynamicKnowledgeRepository to see what develops.

JohnVolkar has passed along the code of the McKessonApsWikiPlugins, which have now gone through a bit of cleanup, new features, etc. and are now distributed under an Apache 2 license as the CeryleWikiPlugins. I'll likely be hosting some of them (the ones specific to their use within Ceryle) on the CeryleWiki and linking from here.

JSPWiki Events Handling#

I whipped up a WikiEvents API for JSPWiki, which is now part of the JSPWiki code base (somewhere in the 2.4.x range, can't remember exactly when). This enables any code that has access to WikiEngine to add listeners to it, or to fire events that any listeners might hear.

The event types are defined as a set of enumerated values in a WikiEventState class (which might also be named WikiEventType). In looking at the ideas expressed on the IdeasEventHandlers page, it might be good to allow some facility for event types defined in a jspwiki.events.properties file to be imported, rather than fixing the set in a class file. It seems like some combination would be good, i.e., that there would be an initial set but that it be extensible via a property file.

    /** Indicates an undefined state. */
     public static final WikiEventState UNDEFINED

     /** Indicates a WikiEngine initialization event, fired as
       * the wiki service is being initialized (in progress). */
     public static final WikiEventState INITIALIZING

     /** Indicates a WikiEngine initialized event, fired after
       * the wiki service is fully available. */
     public static final WikiEventState INITIALIZED

     /** Indicates a WikiEngine closing event, fired prior to
       * a halt of the wiki service. */
     public static final WikiEventState CLOSING

     /** Indicates a WikiEngine stopped event, fired after
       * halting the wiki service. */
     public static final WikiEventState STOPPED

     /** Indicates a exception or error state. */
     public static final WikiEventState ERROR

     /** Indicates a wiki query event. */
     public static final WikiEventState QUERY

This was my first crack at coding for JSPWiki; at the time I was new to the code base except for playing with some plugins. I'd gotten the prototype firing INITIALIZING at the beginning of WikiEngine.initialize() -- right after m_properties has been assigned the parameter value, so they're available from getWikiProperties() -- and INITIALIZED at the end of the method. Everything was up and running in about a day, testament to JSPWiki's design.

The events API allows implementors to modify properties as they're being passed to the engine, using the setWikiProperties() method. This seems to suit my needs, which are specifically to be able to modify the various paths passed to the engine from a parse of WEB-INF/jspwiki.properties.

(I'm still refactoring this section as time permits to move over to its own documentation page)



reverseHeadings Patch#

I just posted a possible patch to JSPWiki 2.2.x, which adds a new property to jspwiki.properties and slightly modifies com.ecyrd.jspwiki.TranslatorReader. When the "reverseHeadings" property is set true (the default is false), the markup used to create <h1> through <h3> is reversed, such that "!" then generates <h1>, and "!!!" creates <h1>. I've been using PMWiki recently, and it uses this "reversed" syntax, which I find a bit more intuitive (since the number of "!" characters equals the heading level). Feel free to incorporate this patch into JSPWiki if you like. It does totally screw up the existing pages' headings, so it would be most useful on new installations. Or, someone could write an awk script to alter the existing pages (if anyone does, please post it here).



Metadata Plugin#

Here's some ideas I started discussing on IdeasMetadata.

I'm looking at various ways of harvesting metadata from wiki pages, such that it could be used for "meta categorization" and creating navigation layers, likely using XML Topic Maps. There's an existing metadata standard that was developed by the library community and is highly advocated for use in web pages, called Dublin Core (DC). The Dublin Core Metadata Element Set (DCMES) is a set of about a dozen elements for common metadata, like author, title, etc. and is used in WorldCat, an international library project that now encompasses over 58 million metadata records in over 9000 libraries. IOW, you can't really go wrong using Dublin Core metadata.

There's even an existing way of encoding DC metadata in HTML <meta> elements, as described in a document Expressing Dublin Core in HTML/XHTML meta and link elements. This basically means you first declare the DC namespace using a <link> element, then in one or more <meta> elements you can embed a DC identifier in the 'name' attribute and the metadata in its 'content' attribute. For example:

  <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
  <meta name="DC.title" lang="en" content="Electric Forest Blog" />
  <meta name="DC.creator" content="Murray Altheim" />
  <meta name="DC.subject" lang="en" content="1. Books. 2. eBooks. 3. Digital Libraries. 4. Topic Maps. 5. Metadata. 6. Information Organization." />
  <meta name="DC.description" lang="en" content="A group blog devoted to discussion of eBooks, digital libraries, and software tools for organizing our thoughts." />
  <meta name="DC.publisher" content="Murray Altheim" />
  <meta name="DC.contributor" content="Murray Altheim, Patrick Durusau, Lee Iverson, Alexander Johannesen, Jack Park, Gary Richmond, Roger Sperberg, Conal Tuohy, Bernard Vatant" />
  <meta name="DC.date" content="2005-05-30" />
  <meta name="DC.type" content="Text" />
  <meta name="DC.format" content="text/html; charset=ISO-8859-1" />
  <meta name="DC.format" content="57486 bytes" />
  <meta name="DC.identifier" content="http://www.altheim.com/ef/" />

Without getting into too much more detail, it's also possible to further characterize DCMES elements with qualifiers and scheme identifiers (e.g., stating what format some data is in), and for this there are additional sets of DC terms, such that it's a relatively rich way of characterizing resources. As a further example (noting that I'm declaring a second namespace, "DCTERMS"):

  <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
  <meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2005-05-30" />
  <meta name="DC.type" scheme="DCTERMS.DCMIType" content="Text" />
  <meta name="DC.identifier" scheme="DCTERMS.URI" content="http://www.altheim.com/ef/" />

Now, this doesn't compare with library MARC records (which have hundreds of fields), but it is certainly suitable for web documents. I'm thinking that if JSPWiki's syntax had a way of either marking off the boundaries for a set of metadata terms, or a way of creating name-value pairs using the "DC" and "DCTERMS" namespaces, it might prove relatively easy to use. And any content so declared could be converted into <meta> elements and embedded in the generated HTML/XHTML documents, which would allow it to be harvested by standardized tools.

I'll be working on something like this for my own purposes but am happy to coordinate with others in the JSPWiki code. I have some ideas for possible syntax, but that can wait until later. I use DC metadata throughout my Ceryle project, so this would all tie in quite nicely.

-- MurrayAltheim, 2005-06-18

Continuing on with this, I'm thinking along the lines of

  [{Meta DC.title "Wuthering Heights"}]
  [{Meta DC.author "Bronte, Emily"}]

or more generically

  [{Meta name "value"}]

which would translate to this in the output:

    <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
    <meta name="DC.title" content="Wuthering Heights" />
    <meta name="DC.author" content="Bronte, Emily" />

(without the head tags, of course)

If people are okay with me calling this MetadataPlugin, I'll get started. Longer term, I'm thinking of several components:

  1. metadata harvester (to grab into memory the metadata found on a page)
  2. <meta> element generator (to take the in-memory metadata and generate <meta> elements to be inserted in <head>
  3. some kind of feature to allow a page's metadata to be deliberately displayed (normally it's hidden)
  4. some kind of UI editor to simplify creation of page metadata (this could be a web form, but better would be an applet that pops up and allows creation/modification from the wiki edit page

I would like some basic guidance (like just a simple paragraph leading me through what will be required for me to code this, e.g., which classes are involved, do I write a filter, etc.) which would save me a LOT of time figuring it out. If this is already available on the wiki, a pointer would be great.



I've written a new LinkParser (which requires a few modifications to JSPWikiMarkupParser) that permits users to add almost all of the <a> (link) attributes declared in HTML, all except those that are security risks. This is now included in the default JSPWiki distribution, and is described in more detail on its own page, AugmentedWikiLinks.

Stuff I'm keeping track of, related to things on JSPWiki.

Who's on?#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 2001:558:6045:59:dc86:7352:6cd4:90ec, 2001:558:6045:59:dc86:7352:6cd4:90ec, 2001:558:6045:59:dc86:7352:6cd4:90ec, 2001:558:6045:59:dc86:7352:6cd4:90ec,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

Pages that I've contaminated #

[idea courtesy of JohnVolkar]

Aggregate Plugin Discussion, Andrew Broughton, Andrew Jaquith, Apache JSP Wiki Manifesto, Better Transclusions, Black Bean Template, Bug Groovy Plugin Does Not Work, Bug Link To Notes Pages Documents, Bug TC.ACL., Ceryle Wiki Plugin Discussion, Ceryle Wiki Plugins, Chat Plugin, Concept Plugin, Conditional Comments, Contributed Plugins, Contributed Template, Daily Razor, Dynamic Knowledge Repository, Entity Reference, Extended Insert Page Plugin, FAQ Administration, FAQ Authentication, FAQ General, Frank_Fischer, GIF, Groovy Plugin, Hello World Plugin, How To Insert A Page, Idea Ability To View Wiki Markup From Page Info, Idea Add Tag Function, Idea Adopt Mediawiki Format, Idea Auto Numbered Headings, Idea Four Heading Levels, Idea Idea Wiki Synchronization Via XMLRPC, Idea Installed Plugins, Idea Noise Bot, Idea Redirect Without Java Script, Idea Redirect Without Java Script By Using Alias, Idea Remove The Chrome From The Edit Page, Idea Reverse Headings, Idea Single Version For Saves By Same User Within Hour, Idea Spellcheck, Idea Subversion Provider Should Go Into Core, Idea Suspicious Edit Flag, Idea Wiki Archive Generator, Ideas Metadata, Ideas Plugin Script Language, Ideas User Preferences, Image, Index Plugin, Inline Image Links, JSP Wiki Coding Standard, JSP Wiki FAQ, JSP Wiki Feature Road Map, JSP Wiki Friendly Web Hosting, JSP Wiki Performance, JSP Wiki V 2 Features, Java Preferences, Java Regular Expressions, Link Index Plugin, Multiple Wikis, Murray Altheim, New Page Handler, Olive Branch Template, Opening Externel Links By Default In A New Window, Page Filter Configuration, Permitted Page Filter, Random Pages Plugin, Redirect Plugin, Regular Expression Syntax, Relaxed Wiki Names, Release 2.2 Discussion, Replacing Reference Manager, Search Enhancements, Short URL Constructor, Spam Filter, Stupid Questions, TESTER_RVM, TODO List, Table Of Contents Plugin, Text Formatting Rules Discussion, Ticker Plugin, Timely Greeting Plugin, Todo Lists Without Plugin, Topical Recent Changes Plugin, Touch Graph Wiki Browser, Transclude Plugin, Transclude Plugin Discussion, Unused Pages Plugin, Upgrading JSP Wiki, Upload Link Tag, Wanted Providers, Wiki As Database, Wiki Events, Wiki Forms Example, Wiki Gardener, Wiki Internationalization API, Wiki Metadata API, Wiki RPC Interface 2, World Wide Web, Xml Storage

I sometimes hang out (when I'm hanging out online) over on CommunityWiki, and maintain both a blog for Ceryle and a group blog called Electric Forest.



Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
reverseHeadings.tar.gz 19.4 kB 1 15-Jun-2005 03:30 MurrayAltheim
« This page (revision-38) was last changed on 10-Oct-2010 16:39 by Dirk Frederickx