I will put all of my jsoncontent-related concerns here for discussion.

• By default, data model should use [] <=> array, and {} <=> stdClass conversion, without forcing {} into arrays. This guarantees perfect round-tripping json->php->json, without breaking on empty objects. MW API has had suffered due to this, lots of complaints :)

• Validation needs to be improved. true/false is not sufficient for validation, need Status object. Status supports notions of "parsable" (valid json), vs "valid" (passes domain-specific validation, e.g. json schema or custom code). Status also supports localized error reporting with more than one issue.

• Separate storage and rendering. Content object is for storage, and when Content::getHtml() is called, its rendering should be done in some other class.

• By default, lets not use visualize JSON as table - this might work in some cases, but it is not easily copiable (without hitting edit). I propose using <syntaxhighlight lang="json">...</syntaxhighlight> if geshi is available, or <code> otherwise.

• JSON should be stored in its compact form, but edited and rendered as "prety-printed".

• It should be possible to store invalid JSON (similar to how it is possible to store Scribunto's Lua code even when it doesn't validate). This is needed when JSON page is used as a template for transclusion into other pages. Example: {"key":{{{1}}} } <-- in this case we obviously skip all the "prety-print" conversions.

(In reply to Yuri Astrakhan from comment #1)

• By default, lets not use visualize JSON as table - this might work in some

cases, but it is not easily copiable (without hitting edit). I propose using
<syntaxhighlight lang="json">...</syntaxhighlight> if geshi is available, or
<code> otherwise.

Geshi support is added by [[mw:Extension:SyntaxHighlight_GeSHi]], let's not do if ( $extension ) { ... } else { ... } in core.
I actually quite like the table, I'm sure we can still provide some way to copy it in action=view without needing to kill the table.

Alex, I am totally ok with the table, but I don't want to duplicate it - I have substantially improved upon Ori's original table code to be more extendable and support validation and other styling. Hence, I would rather have the core provide bare minimum, e.g. render it with <code>...</code>, and let the extension render it in a more visual way. I agree that if (ext) {} else {} should not be in core. This is similar to the code editor - it greatly improves the json editing experience, but we shouldn't rely on it.

Any news on what you guys have done for this? 1.24 is imminent.

So, umm, MW 1.24 shipped… Should I close this as "declined"?

There's been a lot of refactoring, bug fixes, improvements to UI features in the last few weeks by me. @Legoktm and @ori also did a lot of refactoring back in December.

It previously didn't even work on plain MediaWiki core (the only uses of it were in extensions that overwrote significant parts of the system). It now works on plain MediaWiki core, has validation logic, supports all JSON values (not just objects), and various UI improvements.

https://github.com/wikimedia/mediawiki/commits/7c340aed294a80bf/includes/content :

• 7c340aed29 rMW7c340aed294a: JsonContent: Support non-object values as root structure
• e4f84af980 rMWe4f84af980c0: content: Refactor and fix various bugs in JsonContent
• f109074bfe rMWf109074bfeec: Simplify JsonContent::beautifyJSON()
• 00f7c07c02 rMW00f7c07c02f3: content: Deprecate TitleIsCssOrJsPage and TitleIsWikitextPage hooks
• de7cc2c11e rMWde7cc2c11e37: content: Minor clean up to make JsonContent match other classes
• 3a28ee5acb rMW3a28ee5acb7d: CSS/JSON/JavaScript ContentHandler refactoring