Last modified: 2011-12-22 22:37:14 UTC
Created attachment 9020 [details] more call patterns for get and set Currently mw.config.get can be called with: * mw.config.get( 'what' ); * mw.config.get( 'what', 'fallback' ); * mw.config.get( [ 'what1', 'what2' ] ); * mw.config.get( [ 'what1', 'what2' ], 'fallback' ); However mw.config.get should also allow: * mw.config.get( [ 'what1', 'what2' ], [ 'fallback1', 'fallback2' ] ); * mw.config.get( { 'what1': 'fallback1', 'what2': 'fallback2' }); * mw.config.get( [ 'what1', 'what2' ], { 'what1': 'fallback1', 'what2': 'fallback2' }); Currently mw.config.set can be called with: * mw.config.set( 'what', 'value' ); * mw.config.set({ 'what1': 'value1', 'what2': 'value2' }); However mw.config.set should also allow: * mw.config.set( [ 'what1', 'what2' ], [ 'value1', 'value2' ] ); I think these additions would allow more flexibility without having to resort to calling get and set in loops at times. I've included a patch to allow these call patterns.
Created attachment 9285 [details] Patch Reattached as a patch
Could you provide some sort of use case for this? > <RoanKattouw> And I don't want get() to be a screenful of "let's figure out which of the 23 calling conventions was used and what our params are" followed by 5 lines of actual work Is also a concern, unless this is a huge step in some way for de-complexifying some piece of code, I would rather keep those methods simple.
(In reply to comment #2) > Could you provide some sort of use case for this? > [...] unless this is a huge step in some way for de-complexifying > some piece of code, I would rather keep those methods simple. Twinkle, and Navigation Popups are two Gadgets that come to mind as examples where this could be used to simplify code. They both have many configuration options and a need for default settings, and they both have solved the problem in different ways right now.
The general problem of gadget configuration is addressed in Salvatore Ingala's branch, which will hopefully be part of RL2 if time permits.
darklama, here's information about Salvatore Ingala's work: https://www.mediawiki.org/wiki/User:Salvatore_Ingala/Notes especially https://www.mediawiki.org/wiki/User:Salvatore_Ingala/Notes#Integration_howto
I mentioned Gadgets only as examples because they are well known. People also use Gadgets in their user space, and create other custom scripts that make use of configuration settings. My concern is ensuring there is a general and easy way for novelists to easily put together scripts that need to set and retrieve multiple configurations quickly. What Salvatore Ingala wants to do sounds like something already partially implemented at Wikimedia Commons in the form of JSconfig.
Yes, there is full scope overlapping, of course, and I knew of the existence of JSConfig when I started my project. Solutions like JSConfig are probably the nicest thing one can do without relying on some form of server-side support. By the way, mw.config has the "set" method because it's an instance of the mw.Map class, but I think that using mw.config.set in user scripts or gadgets should be strongly discouraged.
(In reply to comment #7) > By the way, mw.config has the "set" method because it's an instance of the > mw.Map class, but I think that using mw.config.set in user scripts or gadgets > should be strongly discouraged. A new Map instance for use by user scripts or gadgets would still make sense, even if mw.config is not used. mw.config.twinkle = new Map(); mw.config.twinkle.set({ showRollbackLinks: [ 'diff', 'others' ], openTalkPageOnAutoRevert: true }); var revertSpecificConfigs = mw.config.twinkle.get({ showRollBacklinks: [], openTalkPageOnAutoRevert: false });
darklama, per automated testing by Rusty Burchfield, your patch doesn't cleanly apply to trunk, since there have been some code changes since September. Could you update your change and then attach the fresh patch? https://www.mediawiki.org/wiki/Patch#Posting_a_patch Sorry for the inconvenience, and thank you for contributing.
(In reply to comment #9) > darklama, per automated testing by Rusty Burchfield, your patch doesn't cleanly > apply to trunk, since there have been some code changes since September. Could > you update your change and then attach the fresh patch? I think it would be better if we waited for an indication from Roan that the patch is likely to be accepted before darklama goes to the trouble of updating it. Roan's comments above imply that this is heading for a WONTFIX.
(In reply to comment #10) > (In reply to comment #9) > > darklama, per automated testing by Rusty Burchfield, your patch doesn't cleanly > > apply to trunk, since there have been some code changes since September. Could > > you update your change and then attach the fresh patch? > > I think it would be better if we waited for an indication from Roan that the > patch is likely to be accepted before darklama goes to the trouble of updating > it. Roan's comments above imply that this is heading for a WONTFIX. Yeah, I should have just WONTFIXed this. Doing so now.
(In reply to comment #8) > A new Map instance for use by user scripts or gadgets would still > make sense, even if mw.config is not used. > > mw.config.twinkle = new Map(); > mw.config.twinkle.set({ > showRollbackLinks: [ 'diff', 'others' ], > openTalkPageOnAutoRevert: true > }); > > var revertSpecificConfigs = mw.config.twinkle.get({ > showRollBacklinks: [], > openTalkPageOnAutoRevert: false > }); This bug already closed but just want to quickly respond to the above. Please don't extend the mw.config objects, certainly not for purposes that is not related to MediaWiki's configuration object at all (since mw.config instance of Map, which would render the mw.config non-standard with an extra member in it). In case you didn't know, the Map constructor is actually a public API that you are encouraged to use if you want to. e.g. mw.twinkle = { conf: new mw.Map(), init: function(){ } ... }
