Jump to content

Topic on Extension talk:Gadgets/Archive 2

Best practice for gadget configuration

3
Inductiveload (talkcontribs)

Hi,

I have a gadget that I'd like to allow a user to be able to optionally configure. For example, say I'd like to pass in a boolean that disables the gadget based on some user logic (e.g. page name + phase of the moon). This config could be quite complex and contain arrays and objects and all sorts of things.

I have seen use of mw.hooks.fire/add, but this seems like it is vulnerable to ordering issues - it's not an issue when loading user scripts, as you can just load the script (which calls hooks.add) after setting up your config object and calling hooks.fire.

The problem is have is that the gadget performs an action pretty much immediately on page load, so it's more than possible the gadget could fire before the user has set the config (in this case, to disable it). For other actions (e.g. something like HotCat where the user will interact with it much later, you can be pretty sure the config got loaded by the time the user comes to interact with it.

However, it also needs to not block forever, as users without extra config should still be able to use the gadget (in the trivial "enable" example, the gadget is always enabled).

Is there a canonical "right way" to pass configuration to gadgets? Thanks!

Peter Bowman (talkcontribs)

Hi. Have you tried API:Options? It allows you to set persistent and per-user configuration values, just remember that keys must start with a userjs- prefix. Retrieval is achieved via mw.user.options.get, which means no asynchronous API calls are involved at all and you can use those values on page load.

Check w:pl:MediaWiki:Gadget-gConfig.js, w:pl:MediaWiki:Gadget-gConfig.css for an implementation of a custom preference manager which also enables a user interface for ease of access and modification of userjs-XXX variables. Of course, you can keep it far more simple than that.

Inductiveload (talkcontribs)

Thanks, that's an interesting approach.

However, it's not quite as flexible as I'd ideally like, since you can only set static values, whereas I'd quite like to be able to dynamically set some options. For example, you might want to disable a gadget based on a page title. Or, more practically, you might want to pass in a list of regexes for page processing.

Reply to "Best practice for gadget configuration"