Page MenuHomePhabricator

Make it possible to create json pages in the module namespace
Open, LowestPublic

Description

Given that I want to create a json page in the Module namespace
And it has the proper .json suffix
When I save the page
Then I expect the new page to be created with the correct content model

What happens is that I get an error message saying that it is not valid Lua code.

It is acceptable to create the page in the user space and then move the page into the module space. It will retain the correct content model, even after editing the page.

A Json page should be handled as if it is a Lua data page, that is it should be loadable with loaddata()

Event Timeline

Given that I want to create a json page in the Module namespace

Why is that a given? I'm inclined to decline this task since it starts from a faulty premise.

It is acceptable to create the page in the user space and then move the page into the module space. It will retain the correct content model, even after editing the page.

Allowing moving non-Scribunto content into Scribunto's namespace is arguably a bug in itself.

Given that I want to create a json page in the Module namespace

Why is that a given? I'm inclined to decline this task since it starts from a faulty premise.

A namespace isn't a content model, it is a group of pages with certain similar features. It is "code", and because of the implementation of loadData() also "codified data", and thus also json. To interprete "Module" as "lua" would lead to a large number of namespaces if we want to add other languages.

It is acceptable to create the page in the user space and then move the page into the module space. It will retain the correct content model, even after editing the page.

Allowing moving non-Scribunto content into Scribunto's namespace is arguably a bug in itself.

No its not, Scribunto should simply handle something that is "lua", and create the page with correct content model, and put the page into whatever namespace the site assigns to such content.

This is closed for a wrong reason, and blocks proper localization by using json files. It also blocks use of json-based configuration files, forcing such files into other non-related namespaces.

I'm reopening this.

Anomie triaged this task as Lowest priority.Jan 19 2019, 2:32 PM

Whatever. I'm not going to bug-war over it with you.

Good arguments are always appreciated.

This is closed for a wrong reason, and blocks proper localization by using json files. It also blocks use of json-based configuration files, forcing such files into other non-related namespaces.

I don't understand this point. We have loadData, which pulls information from a 'static' Lua table or table of tables (i.e. localization, configuration), so it could be used the same way as a Json configuration file, and so doesn't "force such files into other non-related namespaces".

What use case are you actually trying to enable?

I happen to agree with the gist of this task, but I think a reasonable 'fix' to it would be T85847: Grant editcontentmodel right to all logged in users.

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In part, that is an issue of interoperation of two different extensions while this is proposing added behavior to Scribunto. And in particular that one came at it from the perspective of TemplateStyles rather than Scribunto.

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

@Anomie This strikes me in a similar sense to T200914: Allow creation of TemplateStyles in the Module namespace. What's your objection here that wasn't there? That the page is being moved as opposed to being created in the namespace?

In part, that is an issue of interoperation of two different extensions while this is proposing added behavior to Scribunto. And in particular that one came at it from the perspective of TemplateStyles rather than Scribunto.

Okay.

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

There's a use case that Nihiltres was looking at a year or two ago to sync WikiProject colors and names and such for both the metadata gadget as well as WikiProject banners. The gadget of course would like to consume json or something friendly for Javascript; the module behind WikiProject banners would also like to have the color scheme conveniently located. Discussion was at Template talk:WPBannerMeta. I would guess there are other use cases that are similar in that we want one place to store data, not multiple, but more rare than not, and in that specific case, the Json would live as a (sub)page of a particular WikiProject banner in the Template namespace.

Sharing of configurations is an obvious case, reusing localization is another (importing into Mediawiki-space is not always a good idea), and importing data to be reused by Lua scripts.

In part, because this task has yet to include any use case for data to be stored as JSON rather than as a Lua table. It starts from the assumption that JSON is to be used.

There's a use case that Nihiltres was looking at a year or two ago to sync WikiProject colors and names and such for both the metadata gadget as well as WikiProject banners. The gadget of course would like to consume json or something friendly for Javascript; the module behind WikiProject banners would also like to have the color scheme conveniently located. Discussion was at Template talk:WPBannerMeta. I would guess there are other use cases that are similar in that we want one place to store data, not multiple, but more rare than not, and in that specific case, the Json would live as a (sub)page of a particular WikiProject banner in the Template namespace.

FWIW, it's already possible to parse JSON in Lua by using https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#mw.text.jsonDecode

If the main advantage of mw.loadData() is that it is only parsed once, could you write a wrapper Lua module that parses the JSON and returns a Lua table for loadData?

I knew this as I was making my commentary; your comment is a bit tangential, but perhaps we can say that we already have basic level of support in Scribunto and this task would better support JSON. One way to do that for all extensions in this case would be to figure out who other than admin should be able to change the content model of a page, but that's already a different task already linked upward in the page.

If the main advantage of mw.loadData() is that it is only parsed once, could you write a wrapper Lua module that parses the JSON and returns a Lua table for loadData?

I'd actually would like to see a loadJsonData in the library with the same loading characteristics as loadData, as at least one other editor would have liked to store his data in JSON rather than Lua, but I think that's a separate task.

Bits and pieces of JSON is available, some documented, some not. It is pretty weird.