Wikimedia Bugzilla is closed!

There is no use case for this:
* Normal data can be stored as Lua tables in a submodule and loaded with
  mw.loadData()
* Data passed in from templates should be formatted in a manner friendly to
  non-technical users rather than being some blob of JSON
* It's unlikely that an {{#invoke:}} will be used in any context where it makes
  sense to return json rather than wikitext.

There is very nice usecase, otherwise I wouldn't actually file this request.

If you need same data for AJAX JS as well as to be used in the module. Then you will store it only once in JSON format, so it will be available for both JS and Lua.

Please don't close bugs just because you *think* there is no usecase.

(In reply to comment #2)
> Please don't close bugs just because you *think* there is no usecase.

Please always provide a usecase in your initial description if you want to avoid getting WONTFIXed.  :)  https://www.mediawiki.org/wiki/How_to_report_a_bug

Danny: Could you clarify what "some data for JS" is, how it would be "used in the module", and what you'd use it for in both Lua and JS?
Sorry for the hassle, but your example feels still a bit too generic to actually understand the usecase.

Danny: Could you clarify what "some data for JS" is, how it would be "used in
the module", and what you'd use it for in both Lua and JS?

Say you have JSON "database" of some data you want to use both in JavaScript (gadget) as well as in Lua (module).

Trivial (but rather artificial) example:
Array of pairs country code - country name.
Gadget where you put country code in input and it will generate some text to be input into the editbox.
Module where the template param is the country code and it generates some output.
Both need the country name.

Doesn't make a sense to have two "databases", one in JavaScript, one in Lua. Synchronization issues obviously.


----


Another example for why this would be helpful:

Sharing tables between modules via (de)serialization:

Trivial (again artificial for making it really simple) example again:

{{parent|param={{child|foo|bar|baz}}}}

child does #invoke:child, parent does #invoke:parent

module:child simply builds the table { "foo", "bar", "baz" }

module:parent takes the built table (currently impossible, because module can return text only) and uses whatever is there for own purposes

http://www.mediawiki.org/wiki/Module:JSON
..works well enough for my purposes.

Nice, but having such functions provided by default, yet preferably as binaries, thus even better performance, would be obviously better (and this bug is about it). But thanks for the (hopefuly temporary) workaround.

One more use case: https://www.wikidata.org/wiki/Module:WBHacks which is using https://www.wikidata.org/wiki/Module:JSON (different than Ori's). It's hitting the execution limit on pages like https://www.wikidata.org/wiki/Wikidata:P, so a native JSON module might make it faster.

Change 85426 had a related patch set uploaded by Tpt:
(bug 45470) Add mw.json

https://gerrit.wikimedia.org/r/85426

(In reply to comment #1)
>Data passed in from templates should be formatted in a manner friendly to
>non-technical users rather than being some blob of JSON

Ha!
Sure that's why TemplateData and Upload Wizard Campaigns force the user entering raw JSON-data-blobs. From the perspective of their developers and Mr. James Forrester that's totally okay. For me, it wasn't but when I tried to change that, I was accused of "derailing Commons" by them.

(In reply to comment #5)
> Could you clarify what "some data for JS" is, how it would be "used in
> the module", and what you'd use it for in both Lua and JS?
Curretnly I have data (only small that's why I do not complain) in JSON-format for JavaScript, in AbuseFilter format and in Lua format for some edit notice at Commons. JSON is a well-accepted standard and having a fast, native parser and generator would be pretty much useful.