On Jan 17, 2013, at 10:05 AM, Robert Vogel <vogel(a)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(a)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