Page MenuHomePhabricator

Make a config object for each extension/skin, deprecate GlobalVarConfig and RequestContext::getConfig()
Open, Needs TriagePublic

Description

With extension registration, it is now possible to gather the config variables of each extension/skin, separately. So we can make a HashConfig for the defaults of each extension and merge in the user defined settings. Furthermore, we can also make a HashConfig of core default settings then merge in the user defined settings. This means we can deprecate GlobalVarConfig and get rid of most globals. Globals would still be defined in local settings but unset after merging.
RequestContext::getConfig() can then also be deprecated, especially as it doesn't depend on the request as noted in the file. We should instead provide some common objects like APIBase with a config accessor (itself implemented via a MW service). Some modules like RessourceLoader may even want to make their own config independently of the main config.

Event Timeline

Cenarium created this task.Jan 30 2017, 5:27 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2017, 5:27 PM

The before-comma clause looks like T71084: Convert things to use Config classes instead of globals (tracking) and its subtasks?

Well, I feel like we have huge documentation issues regarding current state of the art in config settings, especially for extensions, so I'm not sure. However, I think this task has a bit of a different scope, especially considering this:

We should instead provide some common objects like APIBase with a config accessor (itself implemented via a MW service). Some modules like RessourceLoader may even want to make their own config independently of the main config.

Furthermore, as I see it, this task is more about how xonfig should work for extensions in general, if I take a look on the patch provided for T156877.