jQuery support

Nao

  • Dadman with a boy
  • Posts: 16,079
jQuery support
« on May 6th, 2011, 05:12 PM »Last edited on February 8th, 2013, 10:33 AM
Feature: jQuery support
Developer: Nao
Target: modders, themers, users, geeks
Status: 100% (believed to be complete.)
Comment:

Many SMF mods tend to add jQuery headers to ease their work in the JavaScript department. They would tend to conflict with each other. Add to this various mods that make use of other librairies, and it's become clear that Wedge really needed to have jQuery by default, so as to provide a standard library for all modders.
Wedge offers to load the jQuery library from three different sources: local (if you want to use your own server to provide it and don't mind the extra load on your bandwidth), jQuery CDN or Google CDN. We recommend the Google CDN, which is the most reliable source for providing jQuery. In addition, it always loads fast, and chances are that the library will already be cached on your computer if you tend to visit other websites that also include jQuery from the Google CDN.
We strive to make Wedge compatible with the latest jQuery, but we're currently staying on the 1.5 branch, until they do something about their oversized library. ;)

:edit: They did -- so we're now following the latest branches.

Re: jQuery support
« Reply #31, on February 3rd, 2013, 02:20 PM »
à propos, I use this plugin, Galleriffic. I run the jQuery Migrate Plugin and I noticed that it uses .attr too (if you do a search you can find 12 references),
Should I change those to .prop or can I leave them there? :)

Re: jQuery support
« Reply #32, on February 3rd, 2013, 11:59 PM »
Basically: keep it as it is.

What they're not telling us, or telling us in a convoluted manner, is that:

- you can use .attr() on anything (attributes and properties), jQuery will do the cleaning up,
- you should use .prop() on properties, and you REALLY should use it on properties that accept/return a boolean value (there's a list hidden in the migrate plugin, includes checked, disabled, autoplay, readOnly, etc...)....
- ...BUT you don't HAVE to use .prop() anywhere, it's just a matter of semantics really, and .prop() is also 4 times faster,
- and basically, if you want speed, you should directly access the DOM property, rather than use a jQuery method.

So, in the end: jQuery 1.9 didn't require ANY changes in Wedge, except for the .live() function being removed, and I used it a total of 3 times. The rest is just either semantics on their side, or changes that allow me to save a few extra bytes so I'm adopting them. But even then, it would be easy to come back to a v1.5 implementation.
Re: jQuery support
« Reply #33, on February 4th, 2013, 05:16 PM »
I'm not exactly thrilled with jQuery 1.9, really... -_-

After the .prop() fiasco of today (see thoughts page for this), a new bug has emerged. If you edit a thought that has HTML in it, it gives you an empty text input.

The reason: HTML strings trigger a request to the server to get an HTML-free version. This is sent through Ajax (because we're worthy), and returned via a <?xml> page, processed with responseXML, and shown in the text input.
However, for an unknown reason, even when trying to force the 'xml' dataType, jQuery INSISTS on returning a plain text string instead of an XML object... i.e. the result is in responseText, not responseXML.

It can "easily be fixed" by replacing responseXML with responseText, but... WHY? Oh, WHY???!!!

Why the hell is jQuery full of bugs now? There were a few bugs in v1.5 but they were nothing to be angry about! This one is!
Are we gonna find bugs forever like this? Or will they fix them in v1.9.1 and we just have to be patient..?!
Re: jQuery support
« Reply #34, on February 4th, 2013, 11:13 PM »
So... This is a totally undocumented bug. I don't know if I should care to 'report' it. I've read a bug report from v1.8 saying that the jQuery team has deprecated { async: false } in $.ajax, just because they didn't like that, basically... Apparently to them, it's important that 'A'jax is always 'A'synchronous, so synchronous calls should be done from a function called $.sjax... Lol. Well, anyway, the stuff is still there, and usable and all, but it simply doesn't return a proper responseXML. Only a responseText. So I thought about it and looked into the Wedge codebase, this is the only place where I'm doing a synchronous call, and turning it into an asynchronous call would be disastrous. So, you know what I did...?

I just rewrote Ajax.php to return a simple text string. Voilà. And it makes script.js a bit shorter, too... It's not as clean as before, but anyway we already discussed returning JSON instead of XML for all calls, haven't worked on that because it's a lot of work for a result that may not be that rewarding, but at least in that particular case, getting rid of XML felt good... ;)

Re: jQuery support
« Reply #35, on February 4th, 2013, 11:27 PM »
Quote from Nao on February 4th, 2013, 11:13 PM
So... This is a totally undocumented bug. I don't know if I should care to 'report' it. I've read a bug report from v1.8 saying that the jQuery team has deprecated { async: false } in $.ajax, just because they didn't like that, basically... Apparently to them, it's important that 'A'jax is always 'A'synchronous, so synchronous calls should be done from a function called $.sjax... Lol. Well, anyway, the stuff is still there, and usable and all, but it simply doesn't return a proper responseXML. Only a responseText. So I thought about it and looked into the Wedge codebase, this is the only place where I'm doing a synchronous call, and turning it into an asynchronous call would be disastrous. So, you know what I did...?
Wait, what? Am I seriously reading this correctly?
Quote from Nao on February 4th, 2013, 11:13 PM
I just rewrote Ajax.php to return a simple text string. Voilà. And it makes script.js a bit shorter, too... It's not as clean as before, but anyway we already discussed returning JSON instead of XML for all calls, haven't worked on that because it's a lot of work for a result that may not be that rewarding, but at least in that particular case, getting rid of XML felt good... ;)
That makes a lot of sense :) Actually there aren't many places we do export XML, it's more internal use. I did contemplate - briefly, mind - using JSON for the plugin manager but the one thing XML does that JSON doesn't cleanly do is be able to attach attributes to elements in a multidimensional fashion, e.g. <element attr="value"> without making it another level of nesting.
Posted: February 4th, 2013, 11:25 PM

Also, you're not the Wesley Crusher of gzipping, you're the Data of gzipping. Being the Wesley Crusher makes you the smart-arse no-one likes (and one person even told him to his face that it's a good thing he's cute otherwise he could be obnoxious), whereas being the Data of gzipping means it's cool to be intense about it.

Re: jQuery support
« Reply #36, on February 5th, 2013, 12:58 PM »
Quote from Arantor on February 4th, 2013, 11:27 PM
Quote from Nao on February 4th, 2013, 11:13 PM
So... This is a totally undocumented bug. I don't know if I should care to 'report' it. I've read a bug report from v1.8 saying that the jQuery team has deprecated { async: false } in $.ajax, just because they didn't like that, basically... Apparently to them, it's important that 'A'jax is always 'A'synchronous, so synchronous calls should be done from a function called $.sjax... Lol. Well, anyway, the stuff is still there, and usable and all, but it simply doesn't return a proper responseXML. Only a responseText. So I thought about it and looked into the Wedge codebase, this is the only place where I'm doing a synchronous call, and turning it into an asynchronous call would be disastrous. So, you know what I did...?
Wait, what? Am I seriously reading this correctly?
What? The sjax story? Yes you do...

As for the bug, I decided to report it to the team, because Wedge is one thing, but the entire interwebs (or at least 55% of them) are another.

http://bugs.jquery.com/ticket/13388
Quote
That makes a lot of sense :) Actually there aren't many places we do export XML, it's more internal use. I did contemplate - briefly, mind - using JSON for the plugin manager but the one thing XML does that JSON doesn't cleanly do is be able to attach attributes to elements in a multidimensional fashion, e.g. <element attr="value"> without making it another level of nesting.
Yeah, its main advantage is readability, and this is certainly why we should keep XML to an extent, for instance in plugin(?:-info)?.xml and (?:skin|skeleton-.*?).xml. But for Ajax communication, it would be best to use JSON or text strings. For instance -- in thought XML, we could very simply return the resulting array as a JSON object, it doesn't really need more processing. (Or if need be, can be done earlier in the code than at xml templating time.)

I don't think this is a feature change that would hurt plugins or themes if we postponed it to after the gold release, so it's not urgent whatsoever, but it'd be nice.
Quote
Also, you're not the Wesley Crusher of gzipping, you're the Data of gzipping. Being the Wesley Crusher makes you the smart-arse no-one likes (and one person even told him to his face that it's a good thing he's cute otherwise he could be obnoxious), whereas being the Data of gzipping means it's cool to be intense about it.
It's not about what I WANT to be, it's about being realistic... And in life, I basically behave like an annoying little Wesley Crusher. Especially when you gather a lot of people into a room and someone has the audacity of pronouncing the name of a movie or TV show I recently enjoyed. Then you can't stop me... It becomes all about name dropping. Last Sunday I think I annoyed quite a few people. More Crusher points for me.

Re: jQuery support
« Reply #37, on February 5th, 2013, 04:43 PM »
They appear to have agreed with you about the bug. :)

Re: jQuery support
« Reply #38, on February 6th, 2013, 05:52 PM »
Yeah, and even more amusing, there are more people asking that jQuery fixes it NAO!!!!11
These people probably wouldn't have noticed the bug without my report, though... ;)

But I understand how it is to read something and to immediately be upset because you realize you're concerned and you didn't catch it in the first place.

I'm thinking that the reason for the bug in the first place is that v2.0 was simplified by removing all IE hacks, but this particular one was marked as an IE hack when really it was a generic hack.