D
David Mark
File this under things that jQuery developers don't care about. 
Throw a dart at a printout of the jQuery forum and chances are you will
hit a question like this:-
http://forum.jquery.com/topic/ajax-working-with-firefox-not-ie
"Ajax working with Firefox not IE"
Who could imagine such a thing? The really sick thing is that it (once
again) demonstrates the futility of jQuery's raison d'être, which has
ridiculous problems in IE that the jQuery developers have been notified
about ad nauseam since around the end of 2007.
"I have a jQuery code to allow users to login using a lightbox
(http://colorpowered.com/colorbox/) and immediately start downloading
files, without being redirected or having the page reloaded. It's
perfectly working in Firefox but Internet Explorer keeps showing the
login box until I reload the page"
$(document).ready(function() {
$('a[href^="/link/"]').click(function(event){
var status = $.ajax({
url: "/status",
async: false
}).responseText;
if (status != 'USER_LOGGED_IN')
{
$.fn.colorbox({href:"/login"});
event.preventDefault();
}
});
});
Synchronous XHR? It's beside the point, but certainly suicidal for a
Web page (see also Dojo).
It's hard to say exactly what the problem is as a plug-in (colorBox) is
involved, which means any answers will likely be of the "try this"
guesswork variety.
Regardless, what else is wrong with the above picture? It should be
obvious from the start:-
$('a[href^="/link/"]')
Hmmm. A query that tries to match the start of an attribute containing
a URI. Talk about programming for failure.
http://www.cinsoft.net/attributes.html
It gets repetitive, doesn't it? Not my fault. I've tried everything to
get the jQuery developers to see these (and related) issues. Seems all
I ever get for my trouble is apologists squawking that I am not being
helpful. It's really mind-boggling. Think if I posted an answer in
that forum mentioning this issue that it would get past the jQuery
censor/moderator? I don't as they would seemingly rather save face than
help their users. Or perhaps they are still trying to wrap their
collective brains around this basic IE issue, which has existed since
the late 90's (and continues today in some modes of the latest version).
It's hard to say as their communication skills are lacking as well.
Even if the poster figures out the root problem, do you think they have
tested (or ever will test) in IE < 8 (or IE8 compatibility view?) No
wonder the trend is to shirk such responsibilities as "wastes of time".
The results would really mess with their fantasies, so the blinders are
kept squarely in place. You've really got to pity the people paying for
these efforts. Those are the ones who need to sign up for my support
service. I can spot these (and similar) gaffes from miles away.
Furthermore, do you think any of the "many eyes" in that forum will spot
the mistake? I can't imagine, else the underlying problem in jQuery
would have been fixed by now (roughly 2 and a half years after I first
reported it directly to Resig).
Businesses that are trying to lean on developers who lean on jQuery are
dreaming. How much time is wasted each day on guesswork and head
scratching? It's got to run into the millions of dollars. It's
sickening, but not nearly as offensive as the apologists who brush off
such critical (and patently obvious) failures in the low-level code of
this "mature" framework as unimportant.
So what's the answer? The best one is to avoid using queries.
Furthermore, this is a very good candidate for delegation (and I don't
mean the "Live" bastardization).
Something like this (in a "ready" listener) would do nicely:-
var reDownload = /\/link\//;
document.body.onclick = function(e) {
if (!e) {
e = window.event;
}
var target = e.target || e.srcElement;
if (target.tagName.toLowerCase() == 'a' && reDownload.test(target.href)) {
// Put (async) XHR machinations here.
// In the XHR success callback, depending on the returned result,
// set window.location.href to target.href or open the dialog.
// Post credentials and try again in the dialog success callback.
// Bail out if the dialog fails (is canceled).
return false;
}
};
Pretty simple, but developers will never learn to solve such problems by
copying and pasting jQuery spells. The end result is that baffling
failures lead to unanswered questions in the support forum and
incalculable amounts of wasted time.
The missing scene would require about three lines of code using my XHR
module and alert/dialog add-on. No idea about the colorBox thing, but I
presume that, like most jQuery plug-ins, it is best avoided.
You could also use the rel or class attributes to signal which links
represent downloads. As I've mentioned, I don't care for using the
latter for this purpose and others have stated a distaste for rel in
general. But for portability, virtually anything beats hard-wiring a
partial path in the code.
There's no reliance on convoluted and incompetently written query code
and only one listener is attached, which saves memory. Neither is the
much-maligned "Live" marketecture required (it never is). Win-win-win.
As always, the key to effectively using jQuery is avoiding as much of
it as possible (quite a paradox).
Eventually, you will realize that you can scrape off the last bits and
be rid of it for good (and think of all you will learn in the process).
After all, take away queries (which are provided by most host
environments that jQuery claims to support) and "Live", and what is
left? Basically, a few sub-standard effects and simple utilities
tangled up in an ill-advised and interdependent mess of a design.
DOM0 is used for simplicity in the example. Alternatively, an
addEventListener/attachEvent wrapper could be employed. I'm sure jQuery
has one somewhere.
And, as an aside, why in hell is that method called "click"? The
interface fails as a metaphor as well, so the typical "concise" code
results are illegible to all but jQuery mavens. It's a
self-perpetuating sham on every level. It's no wonder there is so much
anger directed towards criticism of jQuery. The marketers know this
thing will wither and die if exposed to light (and that would be bad for
book sales).
Throw a dart at a printout of the jQuery forum and chances are you will
hit a question like this:-
http://forum.jquery.com/topic/ajax-working-with-firefox-not-ie
"Ajax working with Firefox not IE"
Who could imagine such a thing? The really sick thing is that it (once
again) demonstrates the futility of jQuery's raison d'être, which has
ridiculous problems in IE that the jQuery developers have been notified
about ad nauseam since around the end of 2007.
"I have a jQuery code to allow users to login using a lightbox
(http://colorpowered.com/colorbox/) and immediately start downloading
files, without being redirected or having the page reloaded. It's
perfectly working in Firefox but Internet Explorer keeps showing the
login box until I reload the page
"$(document).ready(function() {
$('a[href^="/link/"]').click(function(event){
var status = $.ajax({
url: "/status",
async: false
}).responseText;
if (status != 'USER_LOGGED_IN')
{
$.fn.colorbox({href:"/login"});
event.preventDefault();
}
});
});
Synchronous XHR? It's beside the point, but certainly suicidal for a
Web page (see also Dojo).
It's hard to say exactly what the problem is as a plug-in (colorBox) is
involved, which means any answers will likely be of the "try this"
guesswork variety.
Regardless, what else is wrong with the above picture? It should be
obvious from the start:-
$('a[href^="/link/"]')
Hmmm. A query that tries to match the start of an attribute containing
a URI. Talk about programming for failure.
http://www.cinsoft.net/attributes.html
It gets repetitive, doesn't it? Not my fault. I've tried everything to
get the jQuery developers to see these (and related) issues. Seems all
I ever get for my trouble is apologists squawking that I am not being
helpful. It's really mind-boggling. Think if I posted an answer in
that forum mentioning this issue that it would get past the jQuery
censor/moderator? I don't as they would seemingly rather save face than
help their users. Or perhaps they are still trying to wrap their
collective brains around this basic IE issue, which has existed since
the late 90's (and continues today in some modes of the latest version).
It's hard to say as their communication skills are lacking as well.
Even if the poster figures out the root problem, do you think they have
tested (or ever will test) in IE < 8 (or IE8 compatibility view?) No
wonder the trend is to shirk such responsibilities as "wastes of time".
The results would really mess with their fantasies, so the blinders are
kept squarely in place. You've really got to pity the people paying for
these efforts. Those are the ones who need to sign up for my support
service. I can spot these (and similar) gaffes from miles away.
Furthermore, do you think any of the "many eyes" in that forum will spot
the mistake? I can't imagine, else the underlying problem in jQuery
would have been fixed by now (roughly 2 and a half years after I first
reported it directly to Resig).
Businesses that are trying to lean on developers who lean on jQuery are
dreaming. How much time is wasted each day on guesswork and head
scratching? It's got to run into the millions of dollars. It's
sickening, but not nearly as offensive as the apologists who brush off
such critical (and patently obvious) failures in the low-level code of
this "mature" framework as unimportant.
So what's the answer? The best one is to avoid using queries.
Furthermore, this is a very good candidate for delegation (and I don't
mean the "Live" bastardization).
Something like this (in a "ready" listener) would do nicely:-
var reDownload = /\/link\//;
document.body.onclick = function(e) {
if (!e) {
e = window.event;
}
var target = e.target || e.srcElement;
if (target.tagName.toLowerCase() == 'a' && reDownload.test(target.href)) {
// Put (async) XHR machinations here.
// In the XHR success callback, depending on the returned result,
// set window.location.href to target.href or open the dialog.
// Post credentials and try again in the dialog success callback.
// Bail out if the dialog fails (is canceled).
return false;
}
};
Pretty simple, but developers will never learn to solve such problems by
copying and pasting jQuery spells. The end result is that baffling
failures lead to unanswered questions in the support forum and
incalculable amounts of wasted time.
The missing scene would require about three lines of code using my XHR
module and alert/dialog add-on. No idea about the colorBox thing, but I
presume that, like most jQuery plug-ins, it is best avoided.
You could also use the rel or class attributes to signal which links
represent downloads. As I've mentioned, I don't care for using the
latter for this purpose and others have stated a distaste for rel in
general. But for portability, virtually anything beats hard-wiring a
partial path in the code.
There's no reliance on convoluted and incompetently written query code
and only one listener is attached, which saves memory. Neither is the
much-maligned "Live" marketecture required (it never is). Win-win-win.
As always, the key to effectively using jQuery is avoiding as much of
it as possible (quite a paradox).
Eventually, you will realize that you can scrape off the last bits and
be rid of it for good (and think of all you will learn in the process).
After all, take away queries (which are provided by most host
environments that jQuery claims to support) and "Live", and what is
left? Basically, a few sub-standard effects and simple utilities
tangled up in an ill-advised and interdependent mess of a design.
DOM0 is used for simplicity in the example. Alternatively, an
addEventListener/attachEvent wrapper could be employed. I'm sure jQuery
has one somewhere.
And, as an aside, why in hell is that method called "click"? The
interface fails as a metaphor as well, so the typical "concise" code
results are illegible to all but jQuery mavens. It's a
self-perpetuating sham on every level. It's no wonder there is so much
anger directed towards criticism of jQuery. The marketers know this
thing will wither and die if exposed to light (and that would be bad for
book sales).