Hi Juan,
Adding markup support would indeed be an excellent extension for jspwiki.
When changing the parser/render as you proposed, this would mean that
for one jspwiki instance the backend storage would be changed from
jspwiki-markup to markdown.
I think this has some important limitations:
- you can not use both markup styles on the same wiki instance
so users familiar with jspwiki-markup would be forced to switch
- we need a solution for migrating a wiki repository between both markups
to allow smooth transitions
- we'll need a rewrite the wysiwyg editors, as they are converting
between html and jspwiki-markup
- as you indicated we need some adaptions to the plain editor
but I believe this would mainly be configuration (I can help with that)
(configuration to adapt the auto-completions, ...)
----
Alternatively, we could look for a solution whereby a user can either use
markdown
or jspwiki-markup, whenever he/she choses to.
In this case, the backend would continue to use jspwiki-markup;
during editing the user can chose another type of input.
The user would then select a "markdown editor" store in its
UserPreferences.
(similar as chosing a wysiwyg editor)
Markdown would be used during editing, and converted to jspwiki-markup
during saving.
With live-preview the user will see immediately the rendered page.
This approach is similar how the wysiwyg editors work, translating between
HTML
and jspwiki-markup when saving the page.
A topic to be addressed is the fact that markdown has a few more features
than jspwiki-markup.
For example, with markdown you can go to 6 levels with headers, jspwiki
has only 3 levels.
I guess most of these cases would be solvable through the use of specific
%%css-class constructs.
To be validated.
----
Finally, we could also opt for a solution to mix different markup styles in
one page.
You can write a page in jspwiki-markup, but if you want to copy/paste some
markdown, it can be put inside a PLUGIN or a %%dynamic-style.
The syntax of a PLUGIN (server side markup conversion) may be a bit too
complex
for most users.
[{MarkdownPlugin
####This Is a Header####
}]
Taking the markdown conversion to the browser-level (with javascript) would
be feasible as well.
(eg showdown http://www.showdownjs.com/ )
%%markdown
####This Is a Header####
/%
----
I believe the 2nd option would be preferred.
However, a faster path to support markdown would be with a plugin or a
dynamic style.
br,
dirk
On Thu, Nov 9, 2017 at 10:00 PM, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:
> Hi!
>
> (last e-mail today, promise)
>
> At work we've built a POC regarding a tool to generate some static sites.
> We're automating JBake site's generation from some assets, templates and
> markdown content (b/c JBake understands markdown). For content authors we
> were looking for a good web-based contents-editor, with versioning
> capabilities, visually appealing, integrated with our ldap... Something
> like JSPWiki O:-) but supporting markdown.
>
> Given that current master allows switching parsers/renderers, I've been
> going at work with some customizations we needed to use JSPWiki for this
> POC, whenever I've could look at the POC. Most of them are specific to our
> infrastructure (workflows, page storage), but the Markdown support is
> pretty agnostic to us so I asked if I could move it to JSPWiki, and I got
> my ok :-)
>
> In order to simplify things regarding code transfer I'll be putting it on a
> personal github repo (my company is already ok with that), AL licensed. I
> have to extract it from our current code-base, so it maybe some days until
> I put it on a github repo for review prior to bringing in to master, but
> this is a heads up.
>
> Regarding the maturity of the development
> * it is POC level, meaning is working and stable, but not feature complete.
> It's enough to demonstrate that JSPWiki can parse/render Markdown, but
> there are some rough edges
> ** JSPWikiMarkupParser does a lot of things (f.ex. generates a hash with a
> link for all headings) that I might overlooked so there might be
> differences
> ** No toolbar support on editors (especially on plain editor). Current
> toolbars aren't thought with multiple parsers on mind, and as the POC
> end-users are more than capable of writing markdown with their bare hands
> :-) I've preferred to focus on working the parser and the renderer than on
> this. In order to be feature complete, this should be done, and I haven't
> thought on a way of doing it yet, so any idea would be more than welcome
> O:-) (probably extending the parsers with a new method to expose the markup
> associated which each toolbar button, and present it through a new JSP or
> who knows how)
> * The parsing / rendering is handled with Flexmark (markdown parser, AL
> licensed) and some extensions. It requires Java 7 (we are on Java 6). Time
> to think on 2.11 O:-)?
>
>
> br,
> juan pablo
>
