Talk:ResourceLoader/Legacy JavaScript/LQT Archive 1

addPortletLink
If addPortletLink is going to be deprecated, I really hope that an equivalent function will be provided to replace it. Adding links to navigation menus is an extremely common task in user scripts, and I really don't want to see us going back to the bad old days when every script writer would roll their own, often half-assed implementation of it. --Ilmari Karonen 22:15, 10 October 2010 (UTC)
 * +1. I don't really understand why we are deprecating the wiki-specific functions of wikibits. I could understand re-implementing things like addPortletLink, jsMsg in terms of jquery where appropriate, but the functions are useful and should stay. It doesn't make sense (imho) to just totally ditch all pre-existing wikibits js. Bawolff 01:25, 11 October 2010 (UTC)

Its being deprecated apparently in favor of mw.util.addPortletLink so an equivalent function will be provided. I wish a skin independent way to get at portlets and to delete portlet links were provided too though. A jsMsg replacement isn't needed at all because of the skin independent way to get at the content body that will make it as easy as  --Darklama 23:56, 3 December 2010 (UTC)
 * is not the same as mw.legacy.wikibits's . The new one is in fact skin independant for all skins supported by core. It adds them to the known portlets when the skins supports it (such as in chick, modern, monobook, myskin, simple and vector), and otherwise it falls back to other locations that are used by the skin to place handy links. Such as #quickbar in the skin 'cologneblue' and 'standard'. And the area before #searchform in 'nostalgia' skin. See also mediaWiki.util.addPortletLink; Krinkle 12:58, 11 December 2010 (UTC)
 * By skin independent I was thinking of something more along the lines of 'toolbox' or 'lang' being passed and it maps it to the correct id for the skin being used. Having looked at the js file, I see that addPortletLink ignores the passed id for some skins and checks if the passed id exists for all other skins. --Darklama 22:03, 11 December 2010 (UTC)

killEvt
In wikibits.js, killEvt is used to kill window events so that, for instance, a link's onClick doesn't also trigger navigation to its href target. Is there a replacement for killEvt? I haven't yet seen how newer MediaWiki code deals with event killing without this. -Memethief 01:33, 12 November 2010 (UTC)


 * jQuery provides event.preventDefault for any browsers that ignore w3 standards and returning false from a jQuery event handler will also stop the default action from happening, which presumably means killEvt isn't needed any more to kill window events. ATM I think they haven't completely stopped using it yet. --Darklama 00:12, 4 December 2010 (UTC)
 * The name of the event object is different per browser and the way to stop the default action (ie. following a link) is also different per browser. However jQuery takes care of this since it maps it all to event.preventDefault. Meaning something like the following works in all browsers (IE 6.0+, FF 2+, Safari 3.0+, Opera 9.0+, Chrome)


 * Also, don't use  unless there is a specific reason you want to do that. It stops other handlers from being triggered and has other downsides. Use e.preventDefault when all you want is stopping the browser from doing it's own thing.
 * wikibit's killEvt was a (fairly complete) function that takes care of a lot of variations in different browsers but does exactly what e.preventDefault does in jQuery it is therefor redundant and not ported to the new ResourceLoader code, since jQuery is now available on all pages by default.
 * Also I'd like to emphasize here that wikibits and the new mw resources are not mutually exclusive. There will be a period of time in which both are available (read also the intro paragraph on ResourceLoader/JavaScript Deprecations).  Krinkle 13:07, 11 December 2010 (UTC)