jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ichiro Furusato <ichiro.furus...@gmail.com>
Subject Re: From Plugin to something completely different... that users need!
Date Wed, 14 Nov 2012 00:48:48 GMT
On Tue, Nov 13, 2012 at 9:19 PM, Christophe Dupriez
<dupriez@squadratic.com> wrote:
> Dear Ichiro,
> Thanks a lot for your long answer! I will try to make a short one:
> 1) for the different Schema.org use cases, what you suggest (if I understand
> you well) is "It is already in the database, stupid!" And you are very well
> right. This means that if one deposit even a simple interwiki link (and a
> template identifier), the interwiki link can be used to identify a database
> object + the identifier to select a JSP template then the Wiki Page can
> simply include the result. This is minimal changes and I will make a try.

I'm not entirely sure what you mean by the "It" in the "It is
already..." and I'm
a bit confused as to how you think the JSP templates are connected to either
the plugin API or to the backend. To my understanding there is a distinct and
desirable independence between them.

I suppose my only point is that a graph-based backend could either be used
in a "flat" manner, where all wiki pages are connected to a single root node,
or a hierarchical (or even graph-structured!) wiki could take advantage of the
actual graph structure of the database. I.e., every graph node has a single,
canonical path -- its connection to its original parent node -- and that path
could be used as the basis of its canonical URL (there could be others,
depending on how it is interconnected to other pages). This whole concept of
a graph-structured wiki is the central innovation in my work, BTW.

> Question to the community: when a plugin has to produce an output, should it
> take its template from some wiki markup in a page or from a JSP template? I
> am more and more attracted by the second rather than the first (I do not see
> end users change the templates and I wish maximal flexibility for them).

Again, confused. A wiki plugin doesn't have any access to its template context,
it only receives a WikiContext and a Map of parameters. It doesn't (necessarily)
have access to either the entire content of the page (though it can of course
gain that via the WikiContext and the WikiEngine) or to its JSP template. So I
don't quite understand where you are going with this.

> 2) the Arbortext DLM concept is very interesting. Do you know any open
> initiative going in the same direction?

No, I'm not aware of anything. It's a very complex project and tied very tightly
to their product line. What I'd aim to do is make an application-independent
link manager.

> 3) XHTML to JSPWiki: Current XHtmlToWikiTranslator is DOM based which is not
> too bad. I am unsure XSLT is easier to develop and maintain than DOM based
> Java procedures.

Actually, the DOM is probably quite a barrier for a number of reasons.
First, it's
very old and clunky technology, an outdated and difficult to use API,
and second,
its performance is pretty poor, especially with large documents. Any translator
should be refactored to use either StAX (ideally), or if a document
object model
is required, then use Apache Axiom (which uses StAX as its stream/events
parser). I've recently been using Axiom and it's very fast, especially using the
Woodstox StAX implementation.

While XSLT experience is certainly rarer than Java experience, actually if the
skills were available, an XSLT approach would be cleaner and easier to maintain.
DOM or other object model approaches to transformation are a great deal more
difficult. XSLT was *designed* for transforming markup.

> For Digital Libraries, DSpace and JSPWiki (SKOS concepts integration), I
> described my work at an ISKO meeting two years ago:
> http://www.iskouk.org/events/presentations/destin-isko-ucl-100929030224-phpapp01.pdf

Thanks -- I'll be sure to look into that as I've long been a fan of
DSpace, though
as yet have not had a chance to do any project work using it.


View raw message