On Jan 17, 2013, at 10:05 AM, Robert Vogel vogel@hallowelt.biz wrote:
@Krinkle: I've written a custom API module that returns categorized results. I wanted to have a categorized output like in this demo: http://jqueryui.com/autocomplete/#categories My first approach was to override some of the logic in "mediawiki.searchSuggest" on the client side. But this didn't work as I expected. Then I saw that "jquery.ui.autocomplete" was part of MW framework and so I tried to use this according to the demo I mentioned before. But "mediawiki.searchSuggest" always "occupied" the input element so I couldn't apply "jquery.ui.autocomplete" to it. But now with the hint from Matt it works pretty good :)
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
On Jan 17, 2013, at 10:05 AM, Robert Vogel vogel@hallowelt.biz wrote:
Are there any future plans to make the removal of already added modules available in ResourceLoader?
When taking the question literally I'd say, no, not ever and for good reason.
Features and modules should not be confused. Removing a module would do nothing but make things crash and fail. If the module is referenced somewhere it is expected to exist and provide a certain API. Removing the module would lead to a missing dependency exception.
Now, one could create a different module in its place with the same name, but that would violate the naming conventions and is generally a bad idea as it defeats the modular design we have. Module names are unique identifiers for a piece of code, not an idea or concept. Loading a module brings the expectation that that exact module is going to be loaded and not some duck punched impersonator in its place that may be implement a similar feature.
Instead you'd register your own module with its own name and make sure it is loaded instead of some other module. The method used can differ based on the feature at hand, but handling this at the module level is not the way to go.
Let's take editors for example. There is a legacy editor, the WikiEditor extension and the VisualEditor extension and many others. They all have their own coding structure, API modules and ResourceLoader modules.
The EditPage provides a hook to change which modules are queued. That's where you hook in, not in the module itself.
I think in the case of SearchSuggest it should probably be loaded by the Skin, not by OutputPage. The only use case I can think of where server-side hooks are not enough (PrefixIndex, API modules etc.), is if the visual presentation (as opposed to the suggested items themselves) needs to be different.
-- Krinkle