6 Sep
2016
6 Sep
'16
10:06 a.m.
Hello,
Well, my suggestion of
yesterday night, comment-like-markers inside the
source stored inside the XARs' XMLs and Wiki content, can make it possible.
> The
drawback is that you cannot have it when you export the page (no bijection).
Yes I
didn’t mention this option because for me it’s not an option and it”s not going to work:
* As you say there’s no bijection, that’s the main issue * won’t fully work in some cases. Imagine a Velocity
macro wrapping an HTML macro. You can edit with a velocity editor but then you loose the
HTML edition or you can edit in an HTML editor but then you loose the velocity syntax.
That is left to the developer to decide with the concept of an include:
if the developer decides that this part is better written as markdown,
properties, groovy, velocity, svg, or html, it's all left to him or her.
This kind of freedom is what makes a source project a valuable asset to
have as opposed to a running programme.
My feeling is that using a specific editor doesn’t
bring that much value compared to editing directly in XWiki (using the syntax hilighiting
and autocompletion extensions). For example I also use IntelliJ IDEA to edit the XWiki .vm
files (velocity content) and I’ve never felt that it was providing a much greater
experience.
Here, I think that you need to take in account people who are really
unused to the XWiki API.
If you use such a comment in velocity files, for example:
#* @vtlvariable name="escapetool"
type="org.apache.velocity.tools.generic.EscapeTool" *# ##
you obtain autocompletion in IntelliJ on the escapetool's function which
I was never able to properly remember.
Surely, there are more experienced XWiki developers out there... But
there are also less experienced ones...
Indeed, however, the HTML that might be generated, as opposed to a wiki
syntax, is never going to be completely decidable within an IDE and I
think that everyone can live with that.
Paul