Last modified: 2012-11-07 21:08:05 UTC
According to the cited reference http://thrivingkings.com/read/Badger-Super-sexy-iOS-style-badges-for-jQuery - one can also use the plugIn with strings. This functionality *has been removed* with change: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blobdiff;f=resources/jquery/jquery.badge.js;h=04495b71672c877c739d754b48f666af314ced69;hp=d40acc6efc51304fa543e5b3b374c610ae57fe36;hb=8dc90f63a800afae9cbdfbaeaae565be987d2238;hpb=44785b25bae7529269f23b2df4aa514dd080f911 Please revert or allow using strings; there is absolutely nothing that would oppose using a single letter instead of a number.
Yes, it did originally allow strings, although this was a bit problematic as the callback function could not be guaranteed a particular type. I didn't see this as a big problem, since JavaScript is tolerant of loose typing, but others objected that it made the callback execution unreliable. Any thoughts on this?
Gerrit is really horrible for browsing... at least if you don't know how-to like me. Loading takes ages and there is no proper syntax-highlighting :-(((( ...and Bugzilla is messing with the links. (In reply to comment #1) If you put a string in, you can't expect useful output. If a callback is supplied and a non-parseable-string was supplied, there are 3 possibilities: # Don't callback. # Callback with the string. # Raise an error. I would prefer #2 or #3. Before, it did #2 and it added the string. Now it does neither callback when supplying a string nor it adds a badge. The callback execution is was not "unreliable" but predictable. Just the arguments passed through the callback depended on the input. But where is the problem with that? After reading the comments in the commit message (is there an easier way to watch them without having to open *each patchset*?), I've the feeling one must read a handbook before one will be able to use gerrrrrrit. For $('<elem>') or $('<elem/>'), why not reading the jQuery-doc? http://api.jquery.com/jQuery/#creating-new-elements
Well, I used it in order to put globalUsage badges on files in a gallery. User had to click the badge, which was a "?" and then global usage was queried. Since no one is willing to fix this issue, I will have to implement my own stuff. For now, I put Infinity on the badges in order to get them back.
OK, I'll change jquery.badge back to accepting numbers or strings and add a warning in the comments that either type may be passed to the callback. If anyone objects, speak now.
while you are at it, you may fix Bug 39383 https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=resources/jquery/jquery.badge.js#l115 This is just appending one line after line 115: return this; so $.fn.badge will return this.
Both issues fixed in https://gerrit.wikimedia.org/r/#/c/32091
This plug-in is poorly designed, IMHO. If the badges can display arbitrary content, just expect string input and let the calling code handle arithmetic. Trying to pack that into the plug-in is dumb, and results in very complicated dance of type checks and typecasts which tries to guess what the user intended. It'd be better to decline to infer / guess and just leave that logic to the user. It reminded me of this: http://imgur.com/EXUmo (in case of link-rot: it's a fake StackOverflow question that pokes fun at the tendency to approach every problem with jQuery.)
We inherited that behavior from the original plug-in code (3rd party). I would be happy to ditch it though if no one objects.
