On Wed, Jun 22, 2011 at 2:32 PM, Krinkle krinklemail@gmail.com wrote:
Brion Vibber wrote:
The sortable table system in MediaWiki was completely rewritten in r86088; unfortunately this was done without benefit of any unit testing or regression testing, and there seem to be a lot of new bugs introduced.
The legacy script was removed from svn without deprecation or quarantine phase, that is in contrary to the descriptoin and expectation set here [1].
It's a reimplementation of an existing system that never gets manually called; since there's no API for it that doesn't really apply -- there's nothing to deprecate.
It needs to *actually work* and not introduce regressions for having been refactored.
I suggest restoring the legacy ts_makeSortable functions in wikibits.js, except for one thing, which is sortables_init, it should not be applied to any table on-load (like nothing in a module should be executed on load, modules should only contain the plugins themselfs!)
To me this doesn't make sense; if it's not to be used, and there's no API designed for using it, and its existing implementation has been replaced, there's no need to keep unused code.
The new jQuery plugin would be in jquery.tablesorter.js which, like any module, also doesn't do anything on-load. Instead it is called in a lazy-loader for tables on the wiki page, this means on a unit test page both can be used seperately on indivudual tables since neither the legacy or the new one is called on load.
That's already how the jQuery module works, yes.
This also makes sure our behaviour is in harmony with the expectation set by our javascript deprecation page [1] and will not break gadgets that are usiung (parts of) the legacy ts_* functions (which are global functions).
Those are internal functions (just poorly namespaced), anything using them can be expected to fail at any time.
So summarized proposal:
- Restore legacy script to comply with the deprecation guide (ie. not
break gadgets that use (parts of) it)
Against -- no public API functions, doesn't apply.
- Write unit tests for the legacy script
Only needed if it's included and used, which is only needed if the new version is reverted
- Write unit tests for hte new script
- Fix the new script
If it's reverted, these should be done during development of the new version prior to commit; if not, do them now.
-- brion