My Library _passes_ TaskSpeed in IE < 7
in [JavaScript]
|
Prev: A good opportunity to investment
Next: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
From: David Mark on 2 Mar 2010 07:32 RobG wrote: > On Feb 19, 6:43 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Tested IE5.5 and IE6 using that IETester thing as my other multi-IE box >> crashed a week ago. Perfect (as expected). Can anyone else see a >> problem in IE < 7? >> >> http://www.cinsoft.net/taskspeed.html > > For a bit of fun I tried Safari 1.0.3 (Mac OS 10.2.8). It wouldn't run > any of the tests at all. Yes, same for IE < 6. The testing framework itself isn't up to the task. :( > For the slickspeed tests, the only libraries > that completed any were jQuery 1.2 and YUI 2.7, which managed to > complete most of them. None of the others could complete any test, all > ending with 'error returned'. The query features are almost certainly pruned in that browser and obviously the SlickSpeed framework doesn't perform any feature detection on the API (e.g. checking to see if the $ function is available). I'd be curious to know if $ (or API.getEBCS) is actually present in that browser (in which case there is an undiscovered hole in the internal feature detection). > > The taskspeed tests at dojotookit.org would not run at all. > > For the dojo slickpeed tests, jQuery 1.2.6, YUI 2.5.2 and Dojo 1.1.1 > did reasonably well. If they didn't pass (or fail in my case) _all_ of them then they didn't do their jobs, allowing the calling app to get inconsistent results. > > I won't be keeping this browser around for long, about to upgrade it > to Mac OS 10.4. I tried IE 5.2 but as expected, nothing ran at all. > The testing framework itself bombs on that browser. I was able to run it in IE5.5 though (and virtually all of the squares were blacked out but the last two columns, which were perfect). :)
From: Scott Sauyet on 2 Mar 2010 09:14 David Mark wrote: > Scott Sauyet wrote: >> I'm not feeling very well and don't have the energy to respond to this >> whole interesting post, but I do want to follow up on this point. > >> I'm not sure how you combine your gateways. If you have multiple >> features being used for one block of code, it's of course >> straightforward to do this: > >> [code deleted see the original if interested: >> http://groups.google.com/group/comp.lang.javascript/msg/3399fd2174a4ac98 ] > >> But to my eyes there's something wrong with this code. I really want >> to run everything else even if rounded corners are not supported. >> That's just a nice tweak. Of course it's easy enough to remove the >> initial API.roundCorners check and add it around the one line where >> it's needed, but you seem to be saying that these should all go at a >> very high level. What am I missing? > > Join the club on not feeling well. Briefly, you aren't missing > anything. There are exceptions to every rule. Hope you're feeling better today. Okay, I think that clears up my confusion. I'm mixed about the dynamic API; I can certainly see some benefits, but I'm not sold on the additional complexities. I'm going to have to think about this some more. -- Scott
From: Ivan S on 2 Mar 2010 12:03 On Mar 2, 10:02 am, Ivan S <ivan.sku...(a)gmail.com> wrote: > On Mar 2, 12:38 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > Scott Sauyet wrote: > > > On Feb 28, 6:12 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > >> Scott Sauyet wrote: > > >>> David Mark wrote: > > >>>> Scott Sauyet wrote: > > >>>>> For instance, this is certainly fine for me: > > > >>>>> API.roundCorners(myDiv); > > >>>>> And this is overkill: > > >>>>> if (API.roundCorners) { > > >>>>> API.roundCorners(myDiv); > > >>>>> } > > >>>> No, you do _not_ do it that way. You do a one-time check at the start > > >>>> for required methods. > > >>> Do you centralize all code that might need rounded corners, then? > > >> I don't think this is a good example feature as it is hard to imagine > > >> code that hinges on rounded-corners. But yes, depending on the > > >> complexity of the applications, you may need to break it up into > > >> sections and use a different gateway for each section. > > > > I'm not feeling very well and don't have the energy to respond to this > > > whole interesting post, but I do want to follow up on this point. > > > > I'm not sure how you combine your gateways. If you have multiple > > > features being used for one block of code, it's of course > > > straightforward to do this: > > > > var myForm = /* ... */, > > > myElt = /* ... */, > > > myContainer = /* ... */; > > > > if (API.attachEvent &&API.validateForm && API.xhr && > > > API.cloneElt && API.appendElt && API.roundCorners) { > > > API.attachEvent(myForm, "submit", function(evt) { > > > if (API.validateForm(myForm) { > > > API.xhr({ > > > method: "POST", > > > url: myForm.action, > > > success: function(data) { > > > var newElt = API.cloneElement(myElt); > > > // update newElt using data; > > > API.appendElt(myContainer, newElt); > > > API.roundCorders(newElt); > > > }, > > > error: function(msg) {/* ... */} > > > }) > > > } > > > }); > > > } > > > > But to my eyes there's something wrong with this code. I really want > > > to run everything else even if rounded corners are not supported. > > > That's just a nice tweak. Of course it's easy enough to remove the > > > initial API.roundCorners check and add it around the one line where > > > it's needed, but you seem to be saying that these should all go at a > > > very high level. What am I missing? > > > Join the club on not feeling well. Briefly, you aren't missing > > anything. There are exceptions to every rule. > > Well, I suppose one could call "API.roundCorners" function (and do > feature test) at the time of creating element (var myElt = /* ... */ > <- here, I suppose), so that "API.cloneElement" would return element > that already has rounded element (or not, if feature is not > available). > > This approach seems better to me, since there is separation of concern > (Ajax - styling). > > Any thoughts about this? :) Now I see I've made a mistake (and was unclear about what I was thinking). It's not "has rounded element" but "has rounded corners". Sorry about that, I haven't drank my first coffee at the time I was writing post, so my brain wasn't functional. :) If this: "Of course it's easy enough to remove the initial API.roundCorners check and add it around the one line where it's needed" does mean adding test like this (as I understood): var myForm = /* ... */, myElt = /* ... */, myContainer = /* ... */; if (API.attachEvent && API.validateForm && API.xhr && API.cloneElt && API.appendElt) { API.attachEvent(myForm, "submit", function(evt) { if (API.validateForm(myForm) { API.xhr({ method: "POST", url: myForm.action, success: function(data) { var newElt = API.cloneElement(myElt); // update newElt using data; API.appendElt(myContainer, newElt); if (API.roundCorners) API.roundCorders(newElt); }, error: function(msg) {/* ... */} }) } }); } Maybe, something like this would be little better: var myForm = /* ... */, myContainer = /* ... */; var myElt = /*...*/; if (API.roundCorners) { API.roundCorners(myElt); } if (API.attachEvent &&API.validateForm && API.xhr && API.cloneElt && API.appendElt) { API.attachEvent(myForm, "submit", function(evt) { if (API.validateForm(myForm) { API.xhr({ method: "POST", url: myForm.action, success: function(data) { var newElt = API.cloneElement(myElt); // update newElt using data; API.appendElt(myContainer, newElt); }, error: function(msg) {/* ... */} }) } }); } This way Ajax functionality isn't "polluted" with styling functionality. *** This isn't so much important, but me personally would make some kind of separation between "this" and "that" functionality. I'm no JS expert, so I don't know is this good approach (in some other languages it is). Any thoughts, this time? :)
From: Scott Sauyet on 2 Mar 2010 13:10 Ivan S wrote: > Ivan S wrote: >> Well, I suppose one could call "API.roundCorners" function (and do >> feature test) at the time of creating element (var myElt = /* ... */ >> <- here, I suppose), so that "API.cloneElement" would return element >> that already has rounded element (or not, if feature is not >> available). > >> This approach seems better to me, since there is separation of concern >> (Ajax - styling). > >> Any thoughts about this? :) > > Now I see I've made a mistake (and was unclear about what I was > thinking). It's not "has rounded element" but "has rounded corners". > Sorry about that, I haven't drank my first coffee at the time I was > writing post, so my brain wasn't functional. :) > > If this: > > "Of course it's easy enough to remove the > initial API.roundCorners check and add it around the one line where > it's needed" > > does mean adding test like this (as I understood): > [ ... ] > if (API.attachEvent && API.validateForm && API.xhr && > API.cloneElt && API.appendElt) { > [ ... ] > var newElt = API.cloneElement(myElt); > if (API.roundCorners) API.roundCorders(newElt); > } > > Maybe, something like this would be little better: > > [ ... ] > if (API.roundCorners) { > API.roundCorners(myElt); > } > > if (API.attachEvent &&API.validateForm && API.xhr && > API.cloneElt && API.appendElt) { > [ ... ] > var newElt = API.cloneElement(myElt); > } > > This way Ajax functionality isn't "polluted" with styling > functionality. Yes, if the rounded corners implementation is such that cloning the relevant element copies along with it any scaffolding used for the rounding, this would work. There are probably implementations which wrap the target element in additional styled DIVs, and such implementation wouldn't allow this technique. But remember that this was just an example. David is suggesting that a few high-level gatekeeper tests can be done on dynamic library methods and then all code guarded by those gatekeepers could be expected to function properly. While that works, the lack of granularity bothers me, and I was trying to show a straightforward example of where that would fall down. Rounded corners is one of my favorite examples of this sort of thing. It's nice to have; designers love it. But I refuse to add the necessary scaffolding to page markup. I will do it in JS, but if it's not supported, they have to live with square boxes! Entangling this nice-to-have feature with more important ones, especially to turn them all off as a group, is unacceptable. David's response is fine: Sometimes you need more than just the high- level gatekeepers. I'd love to see largish examples of code written with this dynamic API/ gatekeeper method. It's simple enough for small things, but it's not at all clear to me how it would scale. -- Scott
From: Ivan S on 2 Mar 2010 16:57
On 2 ožu, 19:10, Scott Sauyet <scott.sau...(a)gmail.com> wrote: Thanks for your answer. :) > I'd love to see largish examples of code written with this dynamic API/ > gatekeeper method.  It's simple enough for small things, but it's not > at all clear to me how it would scale. I like David's idea to abstract several functionality, something like this: if (API.attachEvent && API.validateForm && API.xhr && API.cloneElt && API.appendElt) { if (API.roundCorners) { API.myAjax = function() { // // Ajax functionality with "round corners" } } else { API.myAjax = function() { // Ajax functionality without "round corners" } } } This way API.myAjax can be called without worrying about having "round corners" functionality or not. It looks nice (at least to me), but one thing bugs me. If I have "n" (n - natural number greater than one) functions that I want to abstract, I would have to make every possible combination from "n" of them. Right? That can be quite a work if "n" is large number. Is there any better approach (question is for everyone :) )? Maybe object-oriented approach would be better in cases like this? |