jQuery crashes again
in [JavaScript]
|
Prev: FAQ Topic - How do I generate a random integer from 1 to n? (2010-04-03)
Next: active (x)html newsgroup?
From: David Mark on 6 Apr 2010 22:57 David Mark wrote: > David Mark wrote: >> David Mark wrote: >>> Matt Kruse wrote: >>>> On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>> So, isn't it about time you started using My Library instead? >>>> No. The poorly-documented API kind of sucks. >>>> >>>> Despite its flaws and limitations, I recently used the "sortable" >>>> project of jQuery UI and found it very easy to create an interface to >>>> reorganize content by dragging and dropping things around. All the >>>> options I wanted were there, and it was relatively painless to create >>>> in a small amount of time. When you have that kind of high-level >>>> functionality ready to deliver, documented, tested, and with examples, >>>> let me know. >>>> >>>> Or I also did this: >>>> $('tr.task').live('hover', function() { $ >>>> (this).toggleClass('hover'); }); >>>> >>>> Again, despite its limitations, this was a very easy way to add :hover >>>> support to some table rows in IE6. Does ML make it that easy? >>>> >>> Forgot to translate this for you (though I don't know why I am >>> bothering). You really don't need a toggleClass and I would consider it >>> ill-advised as you should add only on entering and remove on leaving. >>> The jQuery example is ambiguous about that, so prone to get out of sync. >>> >>> Off the top of my head:- >>> >> I suppose I really shouldn't write such things off the top of my head. >> Didn't quite nail the exact behavior now that I look at the original again. >> >> To match behavior that (I think) the OP's tries to implement, I'd need >> something more like these two one-liners:- >> >> var addOrRemoveHoverClass = function(el, b) { >> E(el)[b ? 'addClass' : 'removeClass']('hover'); >> }; >> >> Q('tr.task').onRoll(function(e) { >> addOrRemoveHoverClass(this, true); >> }, function(e) { >> addOrRemoveHoverClass(this); >> }); >> >> Granted, that will attach listeners to each task row, which is hardly >> ideal. However, Resig's scheme is even worse as it will have to run >> *queries* in response to mouseover/out/enter/leave events. Just goes to >> show how queries and other syntactic sugar can get in the way of writing >> efficient applications. >> To be clear, jQuery will use the node test functionality of its query engine on the target elements of these events (delegating from the body of course, which is also less than ideal), walking up the DOM through ancestors until it hits a match (or reaches the top). Any designs that seeks to leverage such a feature in the name of "easiness" (or saving typing or time) are thoroughly ill-advised. I'd say the "live" scheme squanders everything that delegation (without the syntactic sugar and marketing name) saves (and likely more). And what a mess of complications to debug. Not to mention that it rests squarely on the shoulders of jQuery's creaking query engine. No wonder they only "care" about only three or four browsers at a time. :)
From: David Mark on 6 Apr 2010 23:18 Matt Kruse wrote: > On Apr 6, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> I suppose I really shouldn't write such things off the top of my head. >> Didn't quite nail the exact behavior now that I look at the original again. > > I didn't think it was very difficult. But then you are familiar with jQuery's hover "event". > >> To match behavior that (I think) the OP's tries to implement, I'd need >> something more like these two one-liners:- >> var addOrRemoveHoverClass = function(el, b) { >> E(el)[b ? 'addClass' : 'removeClass']('hover'); >> >> }; > > Pretty basic, yes. And basically what is already in jQuery. The toggleClass thing? Are you joking or what? And, as mentioned, ysing that the way you did is thoroughly ill-advised as it can get out of sync. > >> Q('tr.task').onRoll(function(e) { >> addOrRemoveHoverClass(this, true);}, function(e) { >> addOrRemoveHoverClass(this); >> }); >> Granted, that will attach listeners to each task row, which is hardly >> ideal. > > Indeed, not only not ideal, but impractical and a bad idea. No worse than what you did. See here:- http://groups.google.com/group/comp.lang.javascript/msg/233891132e1f15b8 > What does "onRoll" mean? Seems like a very bad name. Actually not if you know what a rollover is. It tracks both overs and outs. See the reference for attachRolloverListener. http://www.cinsoft.net/mylib-doc.asp#attachrolloverlisteners > How do I know if > I need Q() or E()? Seems like the single $() convention is better, as > both return elements to take action on. That's completely ludicrous. It should be obvious if you read the first line of documentation for each (or even if you hadn't). Q is for Query, E is for Element. http://www.cinsoft.net/mylib-doc-objects.html#e http://www.cinsoft.net/mylib-doc-objects.html#q They have many similar methods, but they each also have methods that are appropriate for single and multiple elements respectively. > > I'm not sure why you wouldn't just do this: > Q('tr.task').onRoll(function(e) { > E(this).addClass('hover');}, function(e) { > E(this).removeClass('hover'); > }); > > and avoid the extra function. And that basically mirrors jQuery's > hover() method, right? I did post that one-line variation (sans unneeded e arguments). Might have been another post. > > But in spite of all that, the one-liner I posted actually uses event > delegation, which is the preferred method (especially since in this > example content will be added via ajax). LOL. See cite above. > You can't just ignore that > when writing a comparable solution using ML, can you? I didn't. I left it as an exercise, also explaining why "live" is a complete bastardization of delegation. > >> However, Resig's scheme is even worse as it will have to run >> *queries* in response to mouseover/out/enter/leave events. > > Does it? When? See cite above. > >> This would take a half dozen lines of API code to accomplish with >> delegation. I'll leave that as an exercise. > > Well, it's a trivial one-liner in jQuery and runs quite well. Are you really that thick? It looks trivial to a child. I hope we both know how ungodly and inefficient (not to mention incompetible) it is underneath. > Why > would I switch to ML, which would require me to write a number of > lines of code and which doesn't even have an example of the > functionality? Seems like a step backwards, at least in the API. Nope. You are a step backward and need to catch up to reality. And you seem to be taking an "all things equal" approach by comparing just one example. They aren't even close to start. You know that. > >> Shouldn't be too hard as >> you can inspect the rollover code on the Build Test page. That leads >> straight to a private function that demonstrates how it is done >> (rolloverListenerWithParentCheck). And if you look very carefully, you >> will see there is a missing footnote on the builder (Rollover module >> needs the DOM module to do elements with descendants). That's a >> definite oversight (and a fairly rare sort of caveat), but then when a >> quarter of the Object Reference is still missing (for at least one more >> day), it's not a top priority. > > At this point, I throw up my hands and say "it's not worth it. ML is > clearly not mature. I'm not going to spend hours trying to figure all > that out." You are simply full of it. "Live" does not represent maturation, nor does this insane strategy to leverage it to do rollover effects. Think. > >> And whatever sort of ill-advised scheme is intended, I would advise >> trying a CSS-only solution first. > > Not applicable for IE 6/7. As if jQuery functions anywhere near properly in either of them (or Compatibility View in 8) anyway (i.e. you might be okay of the above is your only line). Very slow and wrong-minded, but okay. > >> Of course, the idea of falling back >> (with a conditional comment) to something like "Live" for IE6's >> "benefit" is pretty ludicrous (for one, IE6 is terribly slow with >> queries). I have to wonder what the OP was trying to accomplish with this. > > Simple highlighting of rows on hover. In this case, the # of rows are > limited, so swapping a class is fine. Aha. So if it is a limited number of rows, mine wins hands down. For starters, yours will be calling listeners with "Sizzle" tests on rolling over (or out of) anything in the document. Mine won't. Yours will be doing all sorts of complex machinations in those listeners. Mine won't. Get the picture? > With more rows, I would > certainly switch to altering the backgroundColor directly. > You would use CSS and fall back to proper delegation if you cared. Switching the styling method will only put a slight dent in your performance deficit. Give it up. There's no free ride. And if there was, it wouldn't be christened jQuery. And as if such a narrow-minded comparison means anything in the big picture. If this is how you evaluate software (the throwing hands up after an hour method let's call it), no wonder you are still stuck on jQuery. ;)
From: David Mark on 6 Apr 2010 23:36 Matt Kruse wrote: > On Apr 6, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> I suppose I really shouldn't write such things off the top of my head. >> Didn't quite nail the exact behavior now that I look at the original again. > > I didn't think it was very difficult. > >> To match behavior that (I think) the OP's tries to implement, I'd need >> something more like these two one-liners:- >> var addOrRemoveHoverClass = function(el, b) { >> E(el)[b ? 'addClass' : 'removeClass']('hover'); >> >> }; > > Pretty basic, yes. And basically what is already in jQuery. > >> Q('tr.task').onRoll(function(e) { >> addOrRemoveHoverClass(this, true);}, function(e) { >> addOrRemoveHoverClass(this); >> }); >> Granted, that will attach listeners to each task row, which is hardly >> ideal. > > Indeed, not only not ideal, but impractical and a bad idea. > What does "onRoll" mean? Seems like a very bad name. How do I know if > I need Q() or E()? Seems like the single $() convention is better, as > both return elements to take action on. > > I'm not sure why you wouldn't just do this: > Q('tr.task').onRoll(function(e) { > E(this).addClass('hover');}, function(e) { > E(this).removeClass('hover'); > }); > > and avoid the extra function. And that basically mirrors jQuery's > hover() method, right? > > But in spite of all that, the one-liner I posted actually uses event > delegation, which is the preferred method (especially since in this > example content will be added via ajax). You can't just ignore that > when writing a comparable solution using ML, can you? > >> However, Resig's scheme is even worse as it will have to run >> *queries* in response to mouseover/out/enter/leave events. > > Does it? When? > >> This would take a half dozen lines of API code to accomplish with >> delegation. I'll leave that as an exercise. > > Well, it's a trivial one-liner in jQuery and runs quite well. Why > would I switch to ML, which would require me to write a number of > lines of code and which doesn't even have an example of the > functionality? Seems like a step backwards, at least in the API. > >> Shouldn't be too hard as >> you can inspect the rollover code on the Build Test page. That leads >> straight to a private function that demonstrates how it is done >> (rolloverListenerWithParentCheck). And if you look very carefully, you >> will see there is a missing footnote on the builder (Rollover module >> needs the DOM module to do elements with descendants). That's a >> definite oversight (and a fairly rare sort of caveat), but then when a >> quarter of the Object Reference is still missing (for at least one more >> day), it's not a top priority. > > At this point, I throw up my hands and say "it's not worth it. ML is > clearly not mature. I'm not going to spend hours trying to figure all > that out." > >> And whatever sort of ill-advised scheme is intended, I would advise >> trying a CSS-only solution first. > > Not applicable for IE 6/7. > And that's not true either (for 7), unless you are talking about quirks mode (something else jQuery doesn't support). So you are really going to eschew a CSS-only solution for an Ajax/jQuery/Live monstrosity, all in the name of IE6? And you base this on the fact that it is one line of code plus a faulty knowledge of IE? If so, I throw my hands up. :) You are clearly not a mature developer. :(
From: Garrett Smith on 7 Apr 2010 01:37 Matt Kruse wrote: > On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> So, isn't it about time you started using My Library instead? > > No. The poorly-documented API kind of sucks. > > Despite its flaws and limitations, I recently used the "sortable" > project of jQuery UI and found it very easy to create an interface to > reorganize content by dragging and dropping things around. All the > options I wanted were there, and it was relatively painless to create > in a small amount of time. When you have that kind of high-level > functionality ready to deliver, documented, tested, and with examples, > let me know. > > Or I also did this: > $('tr.task').live('hover', function() { $ > (this).toggleClass('hover'); }); > APE.dom.toggleClass(el, "hover"); I've just updated the code to use classList. I tested it. With "\r". http://dhtmlkitchen.com/ape/test/tests/dom/classname-f-test.html Code: http://github.com/GarrettS/ape-javascript-library/blob/master/src/dom/classname-f.js No "hover" method, though. I do not generally make methods before I need them. I can see how a `hover` method would be useful. If the need does not present itself, then it won't get added. If it comes to the point where I'm duplicating `hover` type of functionality, I'll look into it. [...] > > I'm not interested in working with the author. I don't like it when David Mark calls me stupid, etc because it hurts the discussion and I don't like to be addressed in such manner. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 7 Apr 2010 03:05
Garrett Smith wrote: > Matt Kruse wrote: >> On Apr 5, 5:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>> So, isn't it about time you started using My Library instead? >> >> No. The poorly-documented API kind of sucks. >> >> Despite its flaws and limitations, I recently used the "sortable" >> project of jQuery UI and found it very easy to create an interface to >> reorganize content by dragging and dropping things around. All the >> options I wanted were there, and it was relatively painless to create >> in a small amount of time. When you have that kind of high-level >> functionality ready to deliver, documented, tested, and with examples, >> let me know. >> >> Or I also did this: >> $('tr.task').live('hover', function() { $ >> (this).toggleClass('hover'); }); >> > > APE.dom.toggleClass(el, "hover"); How lame. You took a bad idea and ran with it. You are just opening up the API for ill-advised designs (like those of Matt Kruse). > > I've just updated the code to use classList. I tested it. With "\r". > http://dhtmlkitchen.com/ape/test/tests/dom/classname-f-test.html > > Code: > http://github.com/GarrettS/ape-javascript-library/blob/master/src/dom/classname-f.js > > > No "hover" method, though. > > I do not generally make methods before I need them. I can see how a > `hover` method would be useful. If the need does not present itself, > then it won't get added. If it comes to the point where I'm duplicating > `hover` type of functionality, I'll look into it. > > [...] > >> >> I'm not interested in working with the author. > I don't like it when David Mark calls me stupid, etc because it hurts > the discussion and I don't like to be addressed in such manner. There you go again. I called you that once in response to some juvenile BS if yours. I don't like it when you post juvenile BS. It wastes my time. And I sure as hell don't need _your_ help. Thanks anyway. |