Hi,
I've been busy on my own projects but under the neocortext.net domain I
will possibly soon be releasing some open source code, mostly related to
digital libraries and ontologies. But there is some JSPWiki related code
as well, as I've been incorporating JSPWiki into some of this other work.
I'm working on a potential replacement DefaultReferenceManager. My first
iteration proved not different enough from the existing code to warrant
the update; yes, it removed some of the strangeness (and eliminated the
serialization/deserialization, which I didn't find useful and created the
possibility of an unsynchronized set of links), but I didn't find it very
elegant, mostly just a cleanup but no real innovation.
So rather than using Sets or Maps, I thought a better and certainly more
interesting approach would use JGraphT to implement a proper graph structure
of links between Pages, Attachments, as well as external links. With some
default predicates that could be expanded so that wiki links could take the
form of subject-predicate-object, i.e., actual tuples. The implementation is
called GraphReferenceManager.
A link in this system could look like:
[Object] # where 'Object' is the target page, the
implicit 'Subject' being the page
containing the link (typical existing link)
[Predicate|Object] # where 'Predicate' expresses the meaning of
the link. Such predicates are wiki pages,
with the three existing links hardwired:
inter-page, attachment, and external links
[Subject|Predicate|Object] # frees the link from its parent page, so
links could be expressed anywhere
I wouldn't introduce any changes to the link parser at first, so this
extended syntax is only a proposal, and the GraphReferenceManager doesn't
conceptionally require the syntax changes, i.e., I'd use hardwired values
for the predicates until such point as predicates were supported in wiki
syntax.
This work raises some questions:
1. would anyone have any issues with introducing JGraphT into the JSPWiki
set of dependencies?
2. would anyone have any issues with introducing Lombok into the JSPWiki
set of dependencies? I'd rather use factories and builders than
constructors, and would also like to avoid explicit getters and
setters. Something like a DSL might be nice.
3. at what point is it planned to bump JSPWiki from Java 8 to say,
Java 11? For my day job I've been doing a fair bit of remediation work
on legacy apps, bumping them *up* to Java 8. But the number of
features I've grown accustomed to in Java 11 makes these features a
bit painful to lose.
4. would the team prefer I develop the reference manager under the
org.apache.wiki.* package or under my own (net.neocortext.wiki.*)?
----
I've also got a couple of JSPWiki plugins, e.g., a QR code plugin, that
are close to ready for usage/testing.
Also my wiki TagManager and associated tag plugins (Tag, Tags, HasTagOf)
have been in use now for I suppose over a decade now on various wikis, so
perhaps the team might be interested in incorporating a tagging
functionality into the Apache code, or I can release it under my own
package name as I have in the past.
Good to see JSPWiki still ticking along, with a new release coming up!
Cheers,
Murray
...........................................................................
Murray Altheim <murray18 at altheim dot com> = = ===
http://www.altheim.com/murray/ === ===
= = ===
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut.
-- Minamoto no Tsunenobu
