Why, exactly, do you want a wikitext intermediary between your JSON and your HTML? The value of wikitext is that it’s a syntax that is easier to edit than HTML. But if it’s not the native format of your data, nor can browsers render it directly, what’s the point of having it? The CollaborationKit extension [0] has two content models, CollaborationHubContent and CollaborationListContent, and they have two different strategies for parsing. CollaborationHubContent takes validated JSON and puts out raw HTML; this is the most straightforward to work with. CollaborationListContent instead puts out wikitext that is fed into the parser, since it is expected that lists can be transcluded onto other pages, and this means using wikitext (as transcluded HTML is not an option). However, this creates a lot of limitations, including parser restrictions that make sense in the context of arbitrary wikitext parsing but not when the markup is provided directly by an extension. The long term plan is for CollaborationListContent to put out HTML, since it’s more straightforward than using a wikitext intermediary that the user does not see anyway. [0] https://www.mediawiki.org/wiki/Extension:CollaborationKit On April 8, 2017 at 11:23:38 PM, Denny Vrandečić (vrandecic(a)gmail.com) wrote: Here's my requirement: - a wiki page is one JSON document - when editing, the user edits the JSON directly - when viewing, I have a viewer that turns the JSON into wikitext, and that wikitext gets rendered as wikitext and turned into HTML by MediaWiki I have several options, including: 1) hook for a tag like <json>, and write an extension that parses the content between the tags and turns it into wikitext (not ideal, as I don't use any of the existing support for JSON stuff, and also I could have several such tags per page, which does not fit with my requirements) 2) I found the JsonConfig extension by yurik. This allows me to do almost all of the things above - but it returns HTML directly, not wikitext. It doesn't seem trivial to be able to return wikitext instead of HTML, but hopefully I am wrong? Also, this ties in nicely with the Code Editor. 3) there is actually a JsonContentHandler in core. But looking through it it seems that this suffers from the same limitations - I can return HTML, but not wikitext. 3 seems to have the advantage to be more actively worked on that 2 (which is not based on 3, probably because it is older than 3). So future goodies like a Json Schema validator will probably go to 3, but not to 2, so I should probably go to 3. Writing this down, one solution could be to create the wikitext, and then call the wikitext parser manually and have it create HTML? I have already developed the extension in 1, and then fully rewritten it in 2. Before I go and rewrite it again in 3, I wanted to ask whether I am doing it right, or if should do it completely differently, and also if there are examples of stuff developed in 3, i.e. of extensions or features using the JsonContent class. Example: I have a JSON document { "username": "Denny" } which gets turned into wikitext ''Hello, [[User:Denny|Denny]]!'' which then gets turned into the right HTML and displayed to the user, e.g. <i>Hello, <a href="...">Denny</a>!</i> Cheers, Denny _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

wrote:

Generating wikitext from some other thing is what Scribunto does.

On Sat, Apr 8, 2017 at 11:30 PM James Hare &lt;jamesmhare(a)gmail.com&gt; wrote: > Why, exactly, do you want a wikitext intermediary between your JSON and > your HTML? The value of wikitext is that it’s a syntax that is easier

Ah, good question indeed. The reason is that users would be actually putting fragments of wikitext into the JSON structure, and then the JSON structure gets assembled into wikitext. Not only would I prefer to have

users work with fragments of wikitext than fragments of HTML, but some things are almost impossible with HTML - e.g. making internal links red

blue depending on the existence of the article, etc.

Ah, good question indeed. The reason is that users would be actually putting fragments of wikitext into the JSON structure, and then the JSON structure gets assembled into wikitext. Not only would I prefer to have

users work with fragments of wikitext than fragments of HTML, but some things are almost impossible with HTML - e.g. making internal links red

blue depending on the existence of the article, etc.

On Sat, Apr 8, 2017 at 11:30 PM James Hare &lt;jamesmhare(a)gmail.com&gt; wrote: Ah, good question indeed. The reason is that users would be actually putting fragments of wikitext into the JSON structure, and then the JSON structure gets assembled into wikitext. Not only would I prefer to have

users work with fragments of wikitext than fragments of HTML, but some things are almost impossible with HTML - e.g. making internal links red

blue depending on the existence of the article, etc.

Here's my requirement: - a wiki page is one JSON document - when editing, the user edits the JSON directly - when viewing, I have a viewer that turns the JSON into wikitext, and

wikitext gets rendered as wikitext and turned into HTML by MediaWiki

Here's my requirement: - a wiki page is one JSON document - when editing, the user edits the JSON directly - when viewing, I have a viewer that turns the JSON into wikitext, and

wikitext gets rendered as wikitext and turned into HTML by MediaWiki I have several options, including: 1) hook for a tag like <json>, and write an extension that parses the content between the tags and turns it into wikitext (not ideal, as I

use any of the existing support for JSON stuff, and also I could have several such tags per page, which does not fit with my requirements) 2) I found the JsonConfig extension by yurik. This allows me to do almost all of the things above - but it returns HTML directly, not wikitext. It doesn't seem trivial to be able to return wikitext instead of HTML, but hopefully I am wrong? Also, this ties in nicely with the Code Editor. 3) there is actually a JsonContentHandler in core. But looking through it it seems that this suffers from the same limitations - I can return HTML, but not wikitext. 3 seems to have the advantage to be more actively worked on that 2 (which is not based on 3, probably because it is older than 3). So future

like a Json Schema validator will probably go to 3, but not to 2, so I should probably go to 3. Writing this down, one solution could be to create the wikitext, and then call the wikitext parser manually and have it create HTML? I have already developed the extension in 1, and then fully rewritten it

2. Before I go and rewrite it again in 3, I wanted to ask whether I am doing it right, or if should do it completely differently, and also if there are examples of stuff developed in 3, i.e. of extensions or

using the JsonContent class. Example: I have a JSON document { "username": "Denny" } which gets turned into wikitext ''Hello, [[User:Denny|Denny]]!'' which then gets turned into the right HTML and displayed to the user,

<i>Hello, <a href="...">Denny</a>!</i> Cheers, Denny _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l