On Tue, Nov 6, 2012 at 7:51 AM, Florian Holeczek <flor...@holeczek.de> wrote:
Hi Christophe,
the template stuff is something that came to my mind, too, already. The
result is a bit like Lotus Notes/Domino, a document-oriented database
(nowadays one would name it NoSQL): Fields which contain (editable) data and
the template providing the non-editable surroundings. However, I think Janne
is right, this is quite a bit away from what a Wiki is.
Hi Florian & Christophe,
[Sorry if this sounds a bit like a rant -- it's not directed at
anyone in particular...]
Most of the fiddling I've done with JSPWiki over the years, and
with digital library-related projects that have used JSPWiki as
a front end, all of them essentially leave the content of the
wiki pages as WikiText and concentrate on providing page-level
metadata, basically like name-value pairs as <meta> elements in
HTML's <head>, with the <body> containing the page content.
Similar to SOAP in this regard as well. Having a proper metadata
carrier for each page has proved invaluable. Then I've just
written plugins to provide the application support I needed that
wasn't native to JSPWiki.
Reading your next lines, I wonder where you're still using wiki markup in
that application. Wouldn't it be best to either customize the JSPs (i.e.
creating a new "template", already today!), or, going one step further,
creating a new webapp and embed JSPWiki functionality into the places you
need wiki markup?
If JSPWiki migrated away from using wiki markup, wiki markup
interpretation, support for the basics of a wiki, well... I'd have
little use for such a beast. I'd just use a CMS. Despite things
going in and out of fashion amongst boy developers (and I accuse
no one here of that), there are some of us "old folks" (older than
our 20s) who still evaluate a technology by what it provides us
rather than it being flashy. Hell, we're already hip by virtue of
being probably the first foray of "social media", do we need to
tweet and gawk and plank and faceplant too? I still find a great
deal of value in wikis, and I don't mind wiki syntax even if some
consider it clunky. The WYSIWYG alternatives have never worked all
that well, and I don't think they ever will, if one of our
requirements is true cross platform independence.
Likewise with JSP. I've countless times read that scriptlets are
bad, blah blah blah, but honestly, for a wiki, and especially for
a wiki that one wants "average" Java developers to be able to
tweek, JSP is brilliant. Sometimes even fun in a kinda retro way,
like fiddling with HyperCard in Mini vMac. It does the job and
it's not overly complicated.
IMO, crucial JSPWiki future topics are:
* explicitly defining the wiki markup syntax (and its transition rules to xhtml)
This isn't all that difficult for the core of the engine. It's only
when we get into extensions and plugins that this gets more
complicated. If there was a way for plugin developers to express
their new syntax in a normalised way, well, that'd be great, but
frankly I don't see people taking the time, call me a pessimist.
* explicitly defining a wiki name syntax
By this I assume you mean explicit rules the constraints on wiki
names. That'll depend on various wiki settings but seems reasonably
simple in theory; like the markup syntax this can almost be
inferred directly from the code.
* a backend which supports proper metadata (Probably JCR is best here, but
not necessarily. The essential thing is a fast and lean backend
implementation which also supports simple file storage.)
I've probably written three or four suitable backends (i.e., the
ability to store wiki page syntax along with a container for metadata)
but it seems people want flexibility in their backends (no pun or joke
intended) so this sounds like a requirement on the API. I wouldn't
object to that at all, would welcome a common metadata API. We already
have the basis of that with the setAttribute() and getAttribute() on
WikiPage, but perhaps firming that up with some specific properties
that would be expected, along the lines of Dublin Core (e.g., Creator,
Created, Modified, Title, etc.). As I said, I've done this a few times
already in past projects -- it's just a matter of having a class defining
the expected values and properly supporting their implementation and
validation.
I know Janne has gone to all that trouble to create Priha, and while
I'm likewise a big fan of JSR-170 and JackRabbit, my own experience in
using it as a backend (for digital library software) was that it was
overly complicated for what I was doing. I've admittedly not been
following this project as closely as I was a few years ago so I don't
know the status of Priha vis a vis JSPWiki, but note that it hasn't
become the default backend, that Janne isn't as heavily involved in
the JSPWiki project, and that Priha seems to have somewhat taken on a
life of its own.
I'd be willing to donate a BerkeleyDB JE based backend that is extremely
fast and has almost no practical limits. But I'd also have to spend some
time cleaning that up (probably not that much but I'm loath to commit to
stuff right now as I've got a lot going on). I tried to upgrade an earlier
version that was embedded in an earlier project but that older project's
dependencies caused me to dump the effort simply on time constraints.
But I've got another wiki-free version of the backend that would just
need some means of supporting revision control and the layering-on of
the WikiPageProvider and/or VersioningFileProvider interfaces. Not
trivial but not a horribly complicated task. I won't have the time to
do this prior to Christmas though unless something in my schedule
lightens up.
* a rendering engine which supports many input formats at once (i.e.
page-wise), based on a MIME type provided via a page's metadata
I either don't understand this suggestion or I do and really don't like
it. Why would we want to support more than simply WikiText? You mean,
like support MS Word, XHTML, other markup? That just sounds complicated,
non-wiki ("supra-wiki"), probably would have serious security issues,
etc., just takes us into the territory of being a CMS that supports a
wiki. I'd rather the project focus down, simplify, and do what it's
already good at: something small, tightly coded with clean APIs, fast,
and easy to extend/modify either with JSPs or plugins. That's what
I've always liked about JSPWiki.
Ichiro
