On Wed, Jun 22, 2011 at 2:32 PM, Krinkle <krinklemail(a)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