Yes, I've been wanting this for a long while.

• Remove inline code
• Move into regular module or into a dynamically generated module (i.e. a new Module class)
• Change JS logic to allow multiple building stages (i.e. addButton should work at any time not just before initialization)
• Make .init() a once-function, and enqueue into document-ready from the 1-line init-module

Note that recently Brion has made some changes in the 1.19-dev version that solved a few problems as well.

• Bug 33922 has been marked as a duplicate of this bug. ***

a.d.bergi wrote:

(In reply to comment #1)

Yes, I've been wanting this for a long while.

:-)

• Change JS logic to allow multiple building stages (i.e. addButton should work

at any time not just before initialization)

• Make .init() a once-function, and enqueue into document-ready from the 1-line

init-module

I would like to see some more functions, which could make it a part of a MVC architecture. I currently think of

• removeButton()
• reload() or, just as well, a public bindable init() function (of course by default on-document-ready, too)

(In reply to comment #3)

(In reply to comment #1)

Yes, I've been wanting this for a long while.

:-)

• Change JS logic to allow multiple building stages (i.e. addButton should work

at any time not just before initialization)

• Make .init() a once-function, and enqueue into document-ready from the 1-line

init-module

I would like to see some more functions, which could make it a part of a MVC
architecture. I currently think of

• removeButton()

Makes sense to have remove, yeah.

• reload() or, just as well, a public bindable init() function (of course by

default on-document-ready, too)

I was thinking of automatically updateing/building the html when calling addButton, removing the need for a public init().

Krinkle, is this really something that needs to block a 1.19 release?

(In reply to comment #5)

Krinkle, is this really something that needs to block a 1.19 release?

Well, I'd say it's your call.

Any code written in 2011 or later should probably be providing tools for users with Vector/WikiEditor, not Monobook/Classic toolbar. WikiEditor has very good javascript hooks whereas the the classic toolbar's are crap (and always have been kind of hacky).

Scripts manipulating the classic toolbar will fail if they load themselves as a resource module because the legacy code for the toolbar bypasses most of resource loader.

-> Either we force users to keep their classic-toolbar enhancement scripts un-resourceloaderified, or the classic toolbar needs to be resource loaderified.

It's not a regression in 1.19, but race conditions are more likely in 1.19 due to speed. And unfortunately, contrary to the module story, there is no "right" way to edit the classic toolbar without having a race condition, simply because the classic toolbar isn't in the normal flow of execution. It exposes a global array where scripts can add things to, and at some point around document-ready event it builds the toolbar with the buttons in the array at that moment, and then the array is further ignored.

Removing as 1.19 blocker.

Fixed by r112451 which build on r111983, r108191, and others.

• Bug 36753 has been marked as a duplicate of this bug. ***