On Jul 18, 3:17 am, Sean Gilligan <[email protected]> wrote: > On 7/17/10 3:26 AM, RobG wrote: > > > On Jul 17, 10:07 am, Sean Gilligan<[email protected]> wrote: > >> The criticism I saw from this guy (over on comp.lang.javascript) was > >> not constructive > > You missed this then: > > > <URL: > >http://groups.google.com.au/group/iphonewebdev/browse_frm/thread/884f... > > Yeah, I saw that one a while back. I didn't know it was the same guy > (but suspected) Many of his points are valid, but most of them are > purely cosmetic and of no consequence for actual users of the script.
The point of many of the criticisms (such as adding listeners to the window object, using get/setAttribute instead of DOM properties, using non-standard properties instead of classes) is that there are more robust ways of doing the same thing that are standards compliant and therefore far less subject to future failure. [...] > >> (and mostly inaccurate) > > Please post one inaccurate statement of any substance that he made > > about iUI. > > On July 27, 2009, he wrote: > > "IUI is only for that one device and uses every wrong- > headed technique in the book, including cramming all content into one > document. It doesn't use the built-in animations and all of the CSS > is based on *attributes* (as opposed to classes.) IIRC, it uses UA > sniffing as well and has been abandoned by its author for years." > > http://groups.google.com/group/comp.lang.javascript/browse_thread/thr... > That was't from the review (which is what I was referring to), so I'll presume you couldn't find an inaccurate statement there. All the criticisms (of that version) stand and the authors would do well to take note and correct them. After all, it's free advice and all of it is technically sound, even if delivered with cod liver oil rather than the more palatable sugar. iUI still has many of the faults pointed out 18 months ago. Like the very first line: window.iui = {... You say it's purely cosmetic, but the window object is a host object. Its behaviour is not covered by *any* standard. Host objects are expressly allowed, by ECMA-262 3 and 5, to behave in any way they want, including not being able to be augmented and so the entire script may fail at the first hurdle. There is a method of declaring a global variable that is absolutely guaranteed to work in any user agent that implements any version of ECMAScript, it even uses fewer characters: var iui = {... While there isn't a browser I know of whose window object can't be augmented, there is no reason to believe one does't exist or won't exist in the future. So given the choice of code that is guaranteed to work for any ECMAScript implementation now and into the future, or code that may fail at some future point purely for the sake of not following standards, why on earth would you choose the second? I see that the following has also survived: | if (!child.id) | child.id = "__" + (++newPageCount) + "__"; Here the id property is read and, if it doesn't exist, a (more or less) random value is added. For what purpose? | var clone = $(child.id); The $ function is simply a wrapper for getElementById. So this statement uses the id (either read from the element or added to it) with getElementById to return exactly the same element. | if (clone) Under what circumstances will clone *not* exist? The loop started with an element, then used getElementById to return exactly the same element. | clone.parentNode.replaceChild(child, clone); Now the element is replaced by itself. What is the purpose of that? | else | document.body.appendChild(child); Under what circumstance is this statement ever executed? Presumably, where clone doesn't exist and getElementById has returned null. But if that was true, surely child doesn't exist either? If that were so, this loop would not be executed at all (for various reasons). | if (child.getAttribute("selected") == "true" || !targetPage) | targetPage = child; Now DOM properties are eschewed in favour of the (known to be buggy) getAttribute method. Further, for those elements where the selected attribute is specified in the W3C DOM HTML specification, it's defined as being a boolean and will return boolean true, not the string true. So this code will *only* work on an element that *doesn't* have a selected attribute specified by the relevant standard. Again, a safe and standards compliant alternative is available at zero extra effort - the class attribute. There is a pattern here. It is these types of basic faults that can be addressed at very little effort and result in a much more robust script. -- Rob -- You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.
