You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Christophe Dupriez <du...@destin.be> on 2012/11/05 09:33:40 UTC
From Plugin to something completely different... that users need!
Hi JspWikiMakers!
About plugin API, I rather agree with the approach "those who follow,
will follow reasonable changes in the good direction". The other will
stay with what they have. What is important is to not forget those
changes in the Release Notes!
Thinking to this and:
1) the problem I have recommending customers to integrate Schema.org
support (HTML5 Microdata; passive SEO where all necessary metadata is
added) and JspWiki (and many others) not really supporting it;
2) the problem I have with CK editor where Wiki->XHTML and back is not
100% faithful (especially with plugins parameters containing special
characters like "%": I solved most other issues),
I am wondering when (AFTER 2.9) / where this could be discussed.
I would dream of a JspWiki 3.0 (to which I would be willing to
contribute) where:
1) we would split current WikiMarkup content in Templates and "fields
content":
Templates would be "free" HTML with possibility to include plugins
Fields content would be text, numbers, dates (etc: pluggable field
content widgets/validators/marshaller/unmarshaller) or XHTML (CK editor)
without the possibility to call plugins
2) Template pages could be instanciated in actual pages where different
fields would be dynamically included. Page headers would also have
access to fields content to fill metadata headers.
For a given Wiki, a "power user" (knowing HTML 5) could create the
necessary templates and the "regular" users would be much more
confortable: only validated text, CK edited text, numbers, dates, etc.
to fill up in a form.
Am I stupid or current JSPs of JSPWiki are the templates I am
dreaming of?
What about the different fields in a single page then?
... the different page types?
... the different field types?
This for me to investigate: any suggestions/examples very welcome!
Jane already declared XHTML content would be something else than
JspWiki. It is true that it begins to look like a collaborative CMS.
What do you think?
Have a nice day!
Christophe
P.S. It is told to me that Drupal is just like that. I do not want to
switch to PHP!!!
Le 5/11/2012 07:23, Florian Holeczek a écrit :
> Hi all,
>
> short answer from me:
>
> +1 for generics
> -1 for 2.9.0
> +1 for a JIRA issue on this topic (FixVersion 2.9.1) with a good
> heading and description, in order to let people explicitely know about
> the change.
>
> BTW: I remember Janne's work on an API - is that still in people's heads?
>
>
> @Ichiro: Where will you publish that stuff? I guess it will be under
> an LGPL license?
>
> I always think it's a pity that there are many JSPWiki plugins out
> there, but they're quite hard to find. WDYT of some kind of extension
> gallery for JSPWiki, partly with links, partly with the possibility of
> hosting the code itself, for example apache-extras, google code or so?
>
> Regards
> Florian
>
> PS @Juan Pablo: Have fun at ApacheCon! Wish I was there too, but there
> was no possibility this time to go there.
>
Re: From Plugin to something completely different... that users need!
Posted by Janne Jalkanen <ja...@ecyrd.com>.
The JCR model is overly complicated and doesn't really provide value - for example, JCR provides versioning, but I had to write my own versioning anyway because I couldn't implement existing JSPWiki functionality with it (I don't remember specifics, it was many years ago). JCR versioning is meant for something else, obviously.
Even stuff like pre-importing sample pages is hard, 'cos the on-disk format isn't standardized. You need to write your own importer.
/Janne
On 13 Nov 2012, at 08:42, Florian Holeczek wrote:
> Hi Janne,
>
>> I wouldn't recommend using JCR anymore for JSPWiki. It is, as you point out, overly complicated and many of its features (like versioning) are ill suited for JSPWiki purposes. Also I'm no longer developing Priha, so someone would need to pick that up too.
>>
>> An redesigned version of the current enhanced with metadata and subpage/subwiki support should be sufficient, something like switching a WikiName class to everywhere that Strings are being used to denote a page, then having it support a simple [subwiki:page1/page2] syntax...
>
> overly complicated is true unfortunately. However, that's mostly the server part's problem, isn't it? Did you face any bigger problems on the client side?
> If there was a fast and lean server already existing, ready to be packaged with JSPWiki, it would be quite comfortable to use JCR. That's why I'm really curious about Jackrabbit OAK.
> On the other hand, looking at the amount of resources available, it may be the better decision to enhance the 2.x API regarding your points above.
>
> Regards
> Florian
Re: From Plugin to something completely different... that users need!
Posted by Florian Holeczek <fl...@holeczek.de>.
Hi Janne,
> I wouldn't recommend using JCR anymore for JSPWiki. It is, as you point out, overly complicated and many of its features (like versioning) are ill suited for JSPWiki purposes. Also I'm no longer developing Priha, so someone would need to pick that up too.
>
> An redesigned version of the current enhanced with metadata and subpage/subwiki support should be sufficient, something like switching a WikiName class to everywhere that Strings are being used to denote a page, then having it support a simple [subwiki:page1/page2] syntax...
overly complicated is true unfortunately. However, that's mostly the server part's problem, isn't it? Did you face any bigger problems on the client side?
If there was a fast and lean server already existing, ready to be packaged with JSPWiki, it would be quite comfortable to use JCR. That's why I'm really curious about Jackrabbit OAK.
On the other hand, looking at the amount of resources available, it may be the better decision to enhance the 2.x API regarding your points above.
Regards
Florian
Re: From Plugin to something completely different... that users need!
Posted by Christophe Dupriez <du...@destin.be>.
In CK editor version 4, there is an interesting possibility for JSPWiki
plugin WYSIWYG editing support:
http://nightly-v4.ckeditor.com/3806/samples/plugins/placeholder/placeholder.html
Have a nice w.e.
Christophe
Le 11/11/2012 15:09, Janne Jalkanen a écrit :
>> 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 wouldn't recommend using JCR anymore for JSPWiki. It is, as you point out, overly complicated and many of its features (like versioning) are ill suited for JSPWiki purposes. Also I'm no longer developing Priha, so someone would need to pick that up too.
>
> An redesigned version of the current enhanced with metadata and subpage/subwiki support should be sufficient, something like switching a WikiName class to everywhere that Strings are being used to denote a page, then having it support a simple [subwiki:page1/page2] syntax...
>
> /Janne
Re: From Plugin to something completely different... that users need!
Posted by Janne Jalkanen <Ja...@ecyrd.com>.
> 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 wouldn't recommend using JCR anymore for JSPWiki. It is, as you point out, overly complicated and many of its features (like versioning) are ill suited for JSPWiki purposes. Also I'm no longer developing Priha, so someone would need to pick that up too.
An redesigned version of the current enhanced with metadata and subpage/subwiki support should be sufficient, something like switching a WikiName class to everywhere that Strings are being used to denote a page, then having it support a simple [subwiki:page1/page2] syntax...
/Janne
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
On Mon, Nov 19, 2012 at 11:08 PM, Christophe Dupriez <du...@destin.be> wrote:
> Dear Ichiro,
[...]
> I would suggest to use your approach (XSLT) if it helps the community to
> contribute.
Hi Christophe,
I've attached an XSLT stylesheet that transforms most of the markup except
for tables and forms (okay, the tougher stuff), nor does it properly handle
link markup. The supporting code is simple enough:
public String transform( Element element, File stylefile )
throws TransformerException
{
try {
// the JDOM Source of the transform
JDOMSource source = new JDOMSource(element);
// the stylesheet Source for the transform
Source stylesheet = new StreamSource(new FileInputStream(stylefile));
// the StringWriter-backed Result of the transform
StringWriter writer = new StringWriter();
Result result = new StreamResult(writer);
TransformerFactory tf = TransformerFactory.newInstance();
Transformer tx = tf.newTransformer(stylesheet);
if ( tx == null ) {
throw new TransformerException("unable to compile stylesheet");
}
tx.transform(source,result);
return writer.toString();
} catch ( TransformerException te ) {
throw new TransformerException("error transforming document: "
+ te.getLocalizedMessage() + "\n" + printStackTrace(te));
} catch ( Exception e ) {
throw new TransformerException( e.getClass().getName()
+ " thrown during transform: " + e.getLocalizedMessage()
+ "\n" + printStackTrace(e));
}
}
You'd likely need to add XML Catalog support (URIResolver) to handle
XHTML files with DOCTYPE declarations, but it's a start. I think even
someone who doesn't really understand XSLT can see how the templates
work and perhaps have a go at adding some of the remaining features.
It's IMO a lot easier than doing this via Java code, where transforms
can easily become spaghetti.
Ichiro
Re: From Plugin to something completely different... that users need!
Posted by Christophe Dupriez <du...@destin.be>.
Dear Ichiro,
I already modified extensively XHtmlElementToWikiTranslator.java to
provide a good coverage of the needs for CK editor
(i.e. I solved all users complaints)
But:
a) it was "trial and error" based
b) it does not support insertion of Plugins correctly
I would suggest to use your approach (XSLT) if it helps the community to
contribute.
Meanwhile, would it be possible to open a branch for the code I already
have to support CK editor?
Who is interested by CK editor???
I am more than ever since I saw with father, 79 years old, despaired to
contribute to Wikipedia, obliged to learn WikiMarkup, when all his
contributions area already redacted in WordPerfect (or Word or whatsoever).
For the support of plugins, it is way better that, as you explain, they
produce XHTML.
This means that some plugins, inheriting from a SNIP plugin to create,
could:
1) collect data from any database or SparQL service
2) format it in XHTML including HTML5 itemscope, itemprop
The insertion of such plugins should be supported in the CK editor...
Thanks a lot for this discussion which clarifies fully the way to go for
me and I hope some manifestation of interest by the community for CK
editing.
I can host an application in my server where one could paste XHTML,
process it using an XSLT and look at the generated WikiMarkup (source
as-is and interpreted by JSPWiki)
I would put that in ASKOSI wiki:
http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=CK-JSPWiki
Would this be suitable for community work on this topic ???
Have a nice day!
Christophe
Le 15/11/2012 05:07, Ichiro Furusato a écrit :
> It occurs to me I didn't actually answer you principal question...
>
> On Wed, Nov 14, 2012 at 11:26 PM, Christophe Dupriez <du...@destin.be> wrote:
> [...]
>> Excuse me to not share your enthusiasm for STAX: it is essential for big
>> documents (I use it for that: RDF to XML transformations...) but WikiPages
>> are not that long and templates are hard enough to keep them unconstrained.
>> Anyway the main problem today is to DEFINE the process to translate
>> (normalize) XHTML into WikiMarkup. XSLT is certainly a way to experiment
>> (and share results). Let's start something like bringing together test
>> cases?
> I think if you were to look at an XSLT approach it's not quite
> so bad. Whereas in XHtmlElementToWikiTranslator.java you see
>
> else if( n.equals( "h2" ) )
> {
> m_out.print( "\n!!! " );
> print( e );
> m_out.println();
> }
>
> basically the pattern in XSLT would be something akin to:
>
> <xsl:template name="h2">
> <xsl:text>
> !!! </xsl:text>
> <xsl:apply-templates/>
> </xsl:template>
>
> where we match via an XPath and output WikiMarkup. It would also
> be a lot more reliable. The big question might seem to be whether
> or not the input XHTML is truly well-formed XML or not. By definition
> in XHTML it *must* be but of course in the real world that might
> not be the case, and the XSLT wouldn't accept non-WF XML. But I'm
> assuming that given the input to XHtmlElementToWikiTranslator.java
> is a DOM Document we're already past that hurdle.
>
> So what we'd need to do to define the transformation would be to
> have a set of XPaths (particular markup patterns in XHTML) and what
> each XPath would generate in WikiMarkup. If we were to go to that
> trouble the XSLT solution would be almost a byproduct of that work.
>
> Ichiro
>
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
It occurs to me I didn't actually answer you principal question...
On Wed, Nov 14, 2012 at 11:26 PM, Christophe Dupriez <du...@destin.be> wrote:
[...]
> Excuse me to not share your enthusiasm for STAX: it is essential for big
> documents (I use it for that: RDF to XML transformations...) but WikiPages
> are not that long and templates are hard enough to keep them unconstrained.
> Anyway the main problem today is to DEFINE the process to translate
> (normalize) XHTML into WikiMarkup. XSLT is certainly a way to experiment
> (and share results). Let's start something like bringing together test
> cases?
I think if you were to look at an XSLT approach it's not quite
so bad. Whereas in XHtmlElementToWikiTranslator.java you see
else if( n.equals( "h2" ) )
{
m_out.print( "\n!!! " );
print( e );
m_out.println();
}
basically the pattern in XSLT would be something akin to:
<xsl:template name="h2">
<xsl:text>
!!! </xsl:text>
<xsl:apply-templates/>
</xsl:template>
where we match via an XPath and output WikiMarkup. It would also
be a lot more reliable. The big question might seem to be whether
or not the input XHTML is truly well-formed XML or not. By definition
in XHTML it *must* be but of course in the real world that might
not be the case, and the XSLT wouldn't accept non-WF XML. But I'm
assuming that given the input to XHtmlElementToWikiTranslator.java
is a DOM Document we're already past that hurdle.
So what we'd need to do to define the transformation would be to
have a set of XPaths (particular markup patterns in XHTML) and what
each XPath would generate in WikiMarkup. If we were to go to that
trouble the XSLT solution would be almost a byproduct of that work.
Ichiro
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
On Wed, Nov 14, 2012 at 11:26 PM, Christophe Dupriez <du...@destin.be> wrote:
> Dear Ichiro,
>
> I take your point that what I propose does not fit in the JSPWiki "spirit".
Hi Christophe,
Honestly, I don't suggest that anyone is in a place to dictate what is
or isn't the spirit of the project -- except perhaps its founder -- but I
think we all have to be mindful of the boundary of what is appropriate
to the project and what are simply our own requirements. And it sounds
like both of us have on occasion extended the feature set of JSPWiki
towards our own ends, as required by specific project requirements.
It's to JSPWiki's credit that it is relatively easy to extend in this
manner (and why on occasion I bemoan its rising complexity).
> The need is to associate parts of a Wiki Page to an "entity", something
> pointed by an URL with data associated with it, data which needs to be
> formatted for display.
>
> From the previous discussion, it is now clear to me that the WikiPage author
> do not need to enter data there but should obtain the desired display by
> just making the reference.
Yes, this seems to be a somewhat common requirement, i.e., the ability to
pull records from a database.
I suppose the only thing I'm suggesting is the idea that *everything*, the
wiki pages, all links, and all referenced entities, all exist in the *same*
database. A radical concept perhaps, and probably not a requirement
for JSPWiki, just a blue sky proposal.
> Let's forget JSP and concentrate on a Plugin like the others: make a generic
> Plugin that can be derived for individual needs allowing to write:
> * [{DLAPA rec="12345"}]
> * [{DLAPA rec="67890"}]
> ...
> This would return WikiMarkup (and not HTML) displaying record 12345 and
> 67890 from source application named "DL" formatted in APA format. For
> another source or another format, another plugin would be defined by a
> programmer.
>
> The plugin would therefore be responsible to access the application, get the
> data and format it in WikiMarkup.
Actually, the contract with a WikiPlugin is that it should return XHTML
markup, since the point in the process workflow in which the plugin is
called is during rendition. If a plugin returned WikiMarkup it would be
displayed as such on the output, not rendered.
That aside, yes, in general a plugin of the form you outline is no issue.
> One generic plugin could be to use SPARQL servers as source, parameterized
> in some configuration files. SPARQL field names could be inserted in some
> WikiMarkup template. Simple and efficient? Example:
> [{SPARQL config="dbpediaCountriesPopulation" param="Belgium"}]
> This would use a configuration "dbpediaCountriesPopulation" to access
> DBPedia and return a WikiMarkup table of Belgium Population statistics
Again, no issue except the plugin would return an XHTML table markup
showing the table of Belgian population statistics.
> Excuse me to not share your enthusiasm for STAX: it is essential for big
> documents (I use it for that: RDF to XML transformations...) but WikiPages
> are not that long and templates are hard enough to keep them unconstrained.
> Anyway the main problem today is to DEFINE the process to translate
> (normalize) XHTML into WikiMarkup. XSLT is certainly a way to experiment
> (and share results). Let's start something like bringing together test
> cases?
StAX is not for big documents, it's simply the streaming XML API used as a
replacement for SAX. The real comparison here is between DOM and Axiom, or
perhaps DOM and another potential replacement such as JDOM or XOM. Anyone
who's had to work with the DOM knows how much of a pain it is, and any of
the replacements are significant improvements. Having a great deal of
experience with pretty much all of them I would at this point recommend
Axiom, for both stability, ease of use by developers, industry support
(it's the OM used by Apache Axis web services) and certainly performance.
So if anyone were to go to the trouble of rewriting the XHTML to WikiMarkup
tools, they would either use Axiom or XSLT. Perhaps we can leave it at that,
as someone would have to step up to the plate to actually do that work. I
can only make recommendations.
> Thanks for the good discussion and have a very nice day!
Likewise, much appreciated.
Ichiro
Re: From Plugin to something completely different... that users need!
Posted by Christophe Dupriez <du...@destin.be>.
Dear Ichiro,
I take your point that what I propose does not fit in the JSPWiki "spirit".
The need is to associate parts of a Wiki Page to an "entity", something
pointed by an URL with data associated with it, data which needs to be
formatted for display.
From the previous discussion, it is now clear to me that the WikiPage
author do not need to enter data there but should obtain the desired
display by just making the reference.
Let's forget JSP and concentrate on a Plugin like the others: make a
generic Plugin that can be derived for individual needs allowing to write:
* [{DLAPA rec="12345"}]
* [{DLAPA rec="67890"}]
...
This would return WikiMarkup (and not HTML) displaying record 12345 and
67890 from source application named "DL" formatted in APA format. For
another source or another format, another plugin would be defined by a
programmer.
The plugin would therefore be responsible to access the application, get
the data and format it in WikiMarkup.
One generic plugin could be to use SPARQL servers as source,
parameterized in some configuration files. SPARQL field names could be
inserted in some WikiMarkup template. Simple and efficient? Example:
[{SPARQL config="dbpediaCountriesPopulation" param="Belgium"}]
This would use a configuration "dbpediaCountriesPopulation" to access
DBPedia and return a WikiMarkup table of Belgium Population statistics
Excuse me to not share your enthusiasm for STAX: it is essential for big
documents (I use it for that: RDF to XML transformations...) but
WikiPages are not that long and templates are hard enough to keep them
unconstrained. Anyway the main problem today is to DEFINE the process to
translate (normalize) XHTML into WikiMarkup. XSLT is certainly a way to
experiment (and share results). Let's start something like bringing
together test cases?
Thanks for the good discussion and have a very nice day!
Christophe
Le 14/11/2012 01:48, Ichiro Furusato a écrit :
> On Tue, Nov 13, 2012 at 9:19 PM, Christophe Dupriez
> <du...@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.
>
> Ichiro
>
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
On Tue, Nov 13, 2012 at 9:19 PM, Christophe Dupriez
<du...@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.
Ichiro
Re: From Plugin to something completely different... that users need!
Posted by Christophe Dupriez <du...@squadratic.com>.
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.
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).
2) the Arbortext DLM concept is very interesting. Do you know any open
initiative going in the same direction?
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.
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
Have a nice day!
Christophe
Le 12/11/2012 12:33, Ichiro Furusato a écrit :
> On Mon, Nov 12, 2012 at 12:53 AM, Christophe Dupriez <du...@destin.be> wrote:
>> Ichiro, please allow me to be very enthusiastic about your message!
> Hi Christophe,
>
> Thanks - I appreciate the enthusiasm. I've got about a half an hour this evening
> to do some emails, so pardon me if I don't address all your many points.
>
>> So, if you have somewhere some demo of your work, I would happy to look at
>> it.
> Sorry, no, the earlier implementations are tied to a specific,
> unreleased project. What I've got now is an almost-complete
> greenfields implementation of the existing node and link APIs,
> and several implementations for those APIs (using Berkeley DB
> JE, JGraphT, and Neo4j). From the implementations you may guess
> this is basically a graph database, where the nodes have an API
> and the links another API.
>
> There's actually a required "root" node called the Reference
> node, such that every node in the database is either connected
> to the reference node or to a node in some way connected to the
> reference node -- there are no "island" nodes -- all nodes in
> the database are connected to something (it's a single graph).
> My plans are to build a link manager akin to a simplified
> version of Arbortext's Dynamic Link Manager (DLM) to handle all
> links using a persistent identifier service. The entire backend
> would be also available via an Apache Wink-based RESTful
> web service (JSPWiki could either access the database via its
> Java API or via REST, though I'm not sure with the latter how
> security would be managed).
>
> As I think I've mentioned previously, a node stores name-value
> pairs, where the metadata is whatever you want to store along
> with the node, and the wiki body is simply another property. This
> is kinda how JackRabbit works -- i.e., it doesn't differentiate
> content from metadata, or just considered the document body
> as more metadata. I at first thought that was strange but I
> couldn't find a reason why it should be considered "wrong".
>
> What does this potentially mean for JSPWiki? Well, my guess is
> that a graph database would suit a flat wiki, but could also
> a hierarchical wiki. Revision control could be implemented as
> graph nodes as revisions connected to the "main" page, with
> links maintained between revisions. This conversation has me
> thinking about actually doing some coding, and I've begun to
> first implement WikiProvider and WikiPageProvider. I can
> release something once those APIs are functional.
>
>> Another point is that is one wants to integrate Schema.org for passive
>> SEO, (s)he will have to find a way to insert structured data:
>> 1) for the whole current page (e.g. data about a family of products, a
>> person, an organisation)
>> 2) for references in the page (e.g. references to people of an organisation,
>> to products of a products' family, etc.)
>> 3) for references in the page providing additional information (e.g. retail
>> prices of the products from a given product family)
> I think these are reasonable use cases but do not think they'd be
> part of the core of JSPWiki -- they'd be extensions of some sort,
> probably plugins.
>
>> For 1):
>> a) identification: my integration with SKOS management is a solution for
>> the applications I develop
>> b) linked attributes/properties: your solution needs to be investigated !
>>
>> For 2), this could be coded using InterWiki links (a given prefix can be
>> associated to an object class and dynamic display could format this
>> correctly. In the example above, InterWiki links of type "jita" is linking
>> to http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=jita_xxxxxx)
>>
>> For 3), it is more difficult as it means to combine a scope (part of the
>> text) and inserted properties values: does your metadata encoding could
>> provide a solution here?
> I've worked with a number of plugins that attempted some structured
> data. If the above-described graph backend were available I'd suggest a
> relatively simple plugin that linked structured data nodes (as separate
> nodes in the database) to instances of plugin references, where the
> plugin would dereference the link and handle the rendering of the data
> (the wiki would do nothing except supply the wiki plugin support). How
> to create, edit and maintain those nodes, well, that would be another
> question.
>
>> About wiki markup:
>> i) I did not succeeded to have MDs learning it well. They prefer CK editor
>> by far (especially it cut and paste from Word capability)
>> ii) CK is XHTML. Converting from WikiMarkup to XHTML is OK. Converting back
>> from XHTML to WikiMarkup is a nightmare. For instance, paragraphs within
>> table cells cannot be supported. Plugins insertions are difficult to
>> retro-convert correctly, etc. If for the different reasons Jane, Florian and
>> you mentionned, we should stick to WikiMarkup, we need to have a process
>> where the user is prevented to make things that are not supported (without
>> destroying the content). I think Florian proposal to describe in details the
>> translation is a very good one.
> If the XHTML is well-formed I would suggest the *only* way to convert it
> back into WikiMarkup would be XSLT. But yes, I agree that is all pretty
> difficult to do. I'm aware of all the long-standing discussions about
> interwiki markup using something like XHTML or bespoke XML markup
> (discussions on CommunityWiki, MeatballWiki, etc.).
>
>> Practically, I would like to put efforts in:
>> a) helping to propose a VersioningFileProvider which stores attributes,
>> based on the developments you already made.
>> Schema.org is proposing a vocabulary going beyond DC as pages can be
>> speaking about a person, a product, etc. etc.
>> I think the metadata properties should be configurable based on a page
>> type (the interwiki code corresponding to the page family)
>> b) comparing my developments for CK editor with latest JSPWiki incarnation
>> to describe what is in there, what I have tried, what remains to be solved
>> c) contribute to a solution (to be invented together!) for storing
>> references, scopes and linked properties within the wiki page text (and
>> editable in CK: a.k. well represented in XHTML)
> Before you jump too far into attempting to describe person, product,
> etc. using some new methodology, consider there have been hundreds
> of projects in a number of fields that have attempted the same thing,
> not to mention all the Ph.D. projects out there that've never got much
> visibility. I'd recommend reading up a bit in digital library texts about
> Faceted Classification, as I'd avoid re-creating what sounds almost
> like an enumerated classification system, very old-school librarian.
> Any data/metadata classification system requires a great deal of effort
> to create and maintain, so if in your experience people have no
> patience with wikitext markup they're not likely to spend a lot of effort
> on a classification system unless they're required to.
>
> Some ideas anyway, and I've run out of time. I always run out of time...
>
> Ichiro
>
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
On Mon, Nov 12, 2012 at 12:53 AM, Christophe Dupriez <du...@destin.be> wrote:
> Ichiro, please allow me to be very enthusiastic about your message!
Hi Christophe,
Thanks - I appreciate the enthusiasm. I've got about a half an hour this evening
to do some emails, so pardon me if I don't address all your many points.
> So, if you have somewhere some demo of your work, I would happy to look at
> it.
Sorry, no, the earlier implementations are tied to a specific,
unreleased project. What I've got now is an almost-complete
greenfields implementation of the existing node and link APIs,
and several implementations for those APIs (using Berkeley DB
JE, JGraphT, and Neo4j). From the implementations you may guess
this is basically a graph database, where the nodes have an API
and the links another API.
There's actually a required "root" node called the Reference
node, such that every node in the database is either connected
to the reference node or to a node in some way connected to the
reference node -- there are no "island" nodes -- all nodes in
the database are connected to something (it's a single graph).
My plans are to build a link manager akin to a simplified
version of Arbortext's Dynamic Link Manager (DLM) to handle all
links using a persistent identifier service. The entire backend
would be also available via an Apache Wink-based RESTful
web service (JSPWiki could either access the database via its
Java API or via REST, though I'm not sure with the latter how
security would be managed).
As I think I've mentioned previously, a node stores name-value
pairs, where the metadata is whatever you want to store along
with the node, and the wiki body is simply another property. This
is kinda how JackRabbit works -- i.e., it doesn't differentiate
content from metadata, or just considered the document body
as more metadata. I at first thought that was strange but I
couldn't find a reason why it should be considered "wrong".
What does this potentially mean for JSPWiki? Well, my guess is
that a graph database would suit a flat wiki, but could also
a hierarchical wiki. Revision control could be implemented as
graph nodes as revisions connected to the "main" page, with
links maintained between revisions. This conversation has me
thinking about actually doing some coding, and I've begun to
first implement WikiProvider and WikiPageProvider. I can
release something once those APIs are functional.
> Another point is that is one wants to integrate Schema.org for passive
> SEO, (s)he will have to find a way to insert structured data:
> 1) for the whole current page (e.g. data about a family of products, a
> person, an organisation)
> 2) for references in the page (e.g. references to people of an organisation,
> to products of a products' family, etc.)
> 3) for references in the page providing additional information (e.g. retail
> prices of the products from a given product family)
I think these are reasonable use cases but do not think they'd be
part of the core of JSPWiki -- they'd be extensions of some sort,
probably plugins.
> For 1):
> a) identification: my integration with SKOS management is a solution for
> the applications I develop
> b) linked attributes/properties: your solution needs to be investigated !
>
> For 2), this could be coded using InterWiki links (a given prefix can be
> associated to an object class and dynamic display could format this
> correctly. In the example above, InterWiki links of type "jita" is linking
> to http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=jita_xxxxxx)
>
> For 3), it is more difficult as it means to combine a scope (part of the
> text) and inserted properties values: does your metadata encoding could
> provide a solution here?
I've worked with a number of plugins that attempted some structured
data. If the above-described graph backend were available I'd suggest a
relatively simple plugin that linked structured data nodes (as separate
nodes in the database) to instances of plugin references, where the
plugin would dereference the link and handle the rendering of the data
(the wiki would do nothing except supply the wiki plugin support). How
to create, edit and maintain those nodes, well, that would be another
question.
> About wiki markup:
> i) I did not succeeded to have MDs learning it well. They prefer CK editor
> by far (especially it cut and paste from Word capability)
> ii) CK is XHTML. Converting from WikiMarkup to XHTML is OK. Converting back
> from XHTML to WikiMarkup is a nightmare. For instance, paragraphs within
> table cells cannot be supported. Plugins insertions are difficult to
> retro-convert correctly, etc. If for the different reasons Jane, Florian and
> you mentionned, we should stick to WikiMarkup, we need to have a process
> where the user is prevented to make things that are not supported (without
> destroying the content). I think Florian proposal to describe in details the
> translation is a very good one.
If the XHTML is well-formed I would suggest the *only* way to convert it
back into WikiMarkup would be XSLT. But yes, I agree that is all pretty
difficult to do. I'm aware of all the long-standing discussions about
interwiki markup using something like XHTML or bespoke XML markup
(discussions on CommunityWiki, MeatballWiki, etc.).
> Practically, I would like to put efforts in:
> a) helping to propose a VersioningFileProvider which stores attributes,
> based on the developments you already made.
> Schema.org is proposing a vocabulary going beyond DC as pages can be
> speaking about a person, a product, etc. etc.
> I think the metadata properties should be configurable based on a page
> type (the interwiki code corresponding to the page family)
> b) comparing my developments for CK editor with latest JSPWiki incarnation
> to describe what is in there, what I have tried, what remains to be solved
> c) contribute to a solution (to be invented together!) for storing
> references, scopes and linked properties within the wiki page text (and
> editable in CK: a.k. well represented in XHTML)
Before you jump too far into attempting to describe person, product,
etc. using some new methodology, consider there have been hundreds
of projects in a number of fields that have attempted the same thing,
not to mention all the Ph.D. projects out there that've never got much
visibility. I'd recommend reading up a bit in digital library texts about
Faceted Classification, as I'd avoid re-creating what sounds almost
like an enumerated classification system, very old-school librarian.
Any data/metadata classification system requires a great deal of effort
to create and maintain, so if in your experience people have no
patience with wikitext markup they're not likely to spend a lot of effort
on a classification system unless they're required to.
Some ideas anyway, and I've run out of time. I always run out of time...
Ichiro
Re: From Plugin to something completely different... that users need!
Posted by Christophe Dupriez <du...@destin.be>.
Ichiro, please allow me to be very enthusiastic about your message!
First let me tell that I integrated JspWiki and the open-source project
ASKOSI.org to control page names through a thesaurus (the page name can
be a SKOS concept code and the displayed title depends of the label
found in the user language + a table is displayed with the hierarchical
and see also relations of the concept). This to integrate thesaurus
searching, JSP Wiki and DSpace digital library.
You can see it at work here (small scale):
http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=jita_THIN
It is in much bigger use internally at Belgium Poison Centre for
describing how to cure people for a substance, a plant, an animal.
Like you, I also find that JSPs are underestimated for "normal"
applications (no reason they are judged less suitable than the
ubiquitous PHP).
Like you, I like a lot the simple VersioningFileProvider and I am not
tempted by more complicated solutions. I have a wiki with 10 thousand
pages: no problem with the files (
http://www.destin-informatique.com/DIRE/ ) but some with the wiki page
names (Florian proposal to clean up this is very welcome!)
So, if you have somewhere some demo of your work, I would happy to look
at it. Another point is that is one wants to integrate Schema.org for
passive SEO, (s)he will have to find a way to insert structured data:
1) for the whole current page (e.g. data about a family of products, a
person, an organisation)
2) for references in the page (e.g. references to people of an
organisation, to products of a products' family, etc.)
3) for references in the page providing additional information (e.g.
retail prices of the products from a given product family)
For 1):
a) identification: my integration with SKOS management is a solution
for the applications I develop
b) linked attributes/properties: your solution needs to be investigated !
For 2), this could be coded using InterWiki links (a given prefix can be
associated to an object class and dynamic display could format this
correctly. In the example above, InterWiki links of type "jita" is
linking to
http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=jita_xxxxxx)
For 3), it is more difficult as it means to combine a scope (part of the
text) and inserted properties values: does your metadata encoding could
provide a solution here?
About wiki markup:
i) I did not succeeded to have MDs learning it well. They prefer CK
editor by far (especially it cut and paste from Word capability)
ii) CK is XHTML. Converting from WikiMarkup to XHTML is OK. Converting
back from XHTML to WikiMarkup is a nightmare. For instance, paragraphs
within table cells cannot be supported. Plugins insertions are difficult
to retro-convert correctly, etc. If for the different reasons Jane,
Florian and you mentionned, we should stick to WikiMarkup, we need to
have a process where the user is prevented to make things that are not
supported (without destroying the content). I think Florian proposal to
describe in details the translation is a very good one.
Practically, I would like to put efforts in:
a) helping to propose a VersioningFileProvider which stores attributes,
based on the developments you already made.
Schema.org is proposing a vocabulary going beyond DC as pages can
be speaking about a person, a product, etc. etc.
I think the metadata properties should be configurable based on a
page type (the interwiki code corresponding to the page family)
b) comparing my developments for CK editor with latest JSPWiki
incarnation to describe what is in there, what I have tried, what
remains to be solved
c) contribute to a solution (to be invented together!) for storing
references, scopes and linked properties within the wiki page text (and
editable in CK: a.k. well represented in XHTML)
Similar discussion than our but for TEI-XML:
http://wiki.tei-c.org/index.php/HTML5_Microdata_TEI_Serialization
Looking for solutions, I find something even more impressive than CK Editor:
http://aloha-editor.org
GPLv2 licence... http://aloha-editor.org/license.php
Thanks for your views Ichiro and Florian and have a nice w.e.
Christophe
Le 11/11/2012 05:35, Ichiro Furusato a écrit :
> On Tue, Nov 6, 2012 at 7:51 AM, Florian Holeczek <fl...@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
>
Re: From Plugin to something completely different... that users need!
Posted by Ichiro Furusato <ic...@gmail.com>.
On Tue, Nov 6, 2012 at 7:51 AM, Florian Holeczek <fl...@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
Re: From Plugin to something completely different... that users need!
Posted by Florian Holeczek <fl...@holeczek.de>.
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.
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?
IMO, crucial JSPWiki future topics are:
* explicitly defining the wiki markup syntax (and its transition rules to xhtml)
* explicitly defining a wiki name syntax
* 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.)
* 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
Any opinions on this?
Regards
Florian
PS: I'm sure you can be saved from switching to PHP ;-)
On 05.11.2012 09:33, Christophe Dupriez wrote:
> Hi JspWikiMakers!
>
> About plugin API, I rather agree with the approach "those who follow, will follow reasonable changes in the good direction". The other will stay with what they have. What is important is to not forget those changes in the Release Notes!
>
> Thinking to this and:
> 1) the problem I have recommending customers to integrate Schema.org support (HTML5 Microdata; passive SEO where all necessary metadata is added) and JspWiki (and many others) not really supporting it;
> 2) the problem I have with CK editor where Wiki->XHTML and back is not 100% faithful (especially with plugins parameters containing special characters like "%": I solved most other issues),
> I am wondering when (AFTER 2.9) / where this could be discussed.
>
> I would dream of a JspWiki 3.0 (to which I would be willing to contribute) where:
> 1) we would split current WikiMarkup content in Templates and "fields content":
> Templates would be "free" HTML with possibility to include plugins
> Fields content would be text, numbers, dates (etc: pluggable field content widgets/validators/marshaller/unmarshaller) or XHTML (CK editor) without the possibility to call plugins
> 2) Template pages could be instanciated in actual pages where different fields would be dynamically included. Page headers would also have access to fields content to fill metadata headers.
>
> For a given Wiki, a "power user" (knowing HTML 5) could create the necessary templates and the "regular" users would be much more confortable: only validated text, CK edited text, numbers, dates, etc. to fill up in a form.
>
> Am I stupid or current JSPs of JSPWiki are the templates I am dreaming of?
> What about the different fields in a single page then?
> ... the different page types?
> ... the different field types?
> This for me to investigate: any suggestions/examples very welcome!
>
> Jane already declared XHTML content would be something else than JspWiki. It is true that it begins to look like a collaborative CMS.
>
> What do you think?
>
> Have a nice day!
>
> Christophe
>
> P.S. It is told to me that Drupal is just like that. I do not want to switch to PHP!!!
>
> Le 5/11/2012 07:23, Florian Holeczek a écrit :
>> Hi all,
>>
>> short answer from me:
>>
>> +1 for generics
>> -1 for 2.9.0
>> +1 for a JIRA issue on this topic (FixVersion 2.9.1) with a good heading and description, in order to let people explicitely know about the change.
>>
>> BTW: I remember Janne's work on an API - is that still in people's heads?
>>
>>
>> @Ichiro: Where will you publish that stuff? I guess it will be under an LGPL license?
>>
>> I always think it's a pity that there are many JSPWiki plugins out there, but they're quite hard to find. WDYT of some kind of extension gallery for JSPWiki, partly with links, partly with the possibility of hosting the code itself, for example apache-extras, google code or so?
>>
>> Regards
>> Florian
>>
>> PS @Juan Pablo: Have fun at ApacheCon! Wish I was there too, but there was no possibility this time to go there.
>>
>