Prev: FAQ Topic - How can I access the client-side filesystem? (2010-05-11)
Next: apparently wrong function.
From: Thomas 'PointedEars' Lahn on 12 May 2010 13:07 Matt Kruse wrote: > Thomas 'PointedEars' Lahn wrote: >> Matt Kruse wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> > I'm not building this for idiots! >> >> ISTM you are not building this for people who do DOM scripting either. >> >> <form>...<input name="foo[]">...</form> >> > This already works fine: >> > $prop(document, "forms[0].foo[].value") >> > for example. >> You miss the point. > > On the contrary, you fail to make one. It is not that hard to miss, see <news:2882225.eEdlvqk35O(a)PointedEars.de>. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Thomas 'PointedEars' Lahn on 12 May 2010 13:13 Matt Kruse wrote: > Thomas 'PointedEars' Lahn wrote: >> Your shortsightedness blinds you again for the possibilities that await >> you. As long as you choose string delimiters for separating parts of the >> /MemberExpression/ used to access a property, your implementation will >> not be able to deal with objects that have properties with names that >> contain those delimiters. > > [...] > Matt "the key to picking a good delimiter is to use one that is not > contained in your string expression" Kruse How naive are you anyway? *Any* Unicode character may be contained in a property name. The only way for you to work around that problem is to provide a way for the user of the function/library to define the delimiter(s) before or upon the call and to make the provision that property names of the object do not contain it/them. However, no such provision is necessary and it it is more efficient, a lot more simple and compatible not to use a string delimiter that you need to split on in the first place. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Scott Sauyet on 12 May 2010 13:16 Thomas 'PointedEars' Lahn wrote: > Matt Kruse wrote: >> Thomas 'PointedEars' Lahn wrote: >>> No, by contrast you will not be able to handle property names that >>> contain `|'. > >> Umm, then you just pick a different delimiter that doesn't conflict >> with your property names. Duh. > > Your shortsightedness blinds you again for the possibilities that await you. > As long as you choose string delimiters for separating parts of the > /MemberExpression/ used to access a property, your implementation will not > be able to deal with objects that have properties with names that contain > those delimiters. While I agree with what seems to be the majority opinion that strings with delimiters are not the best solution, I'm not sure I can buy this objection. Matt said he was passing alternative delimiters as an additional parameter to the call. Since the presumed use is something like var xyz = $prop(document, "forms[0].foo[].value"); or if necessary, var xyz = $prop(obj, 'property|.property.|[property]', '|'); and not var xyz = $prop(obj, myStringVar); it's easy enough to see by inspection that the delimiter is not included in the string. The point is that this is to be used for known source code and data structures; it's simply a mechanism to avoid the nested chains of checking on the existence of intermediate properties on the chain. It's not, in my understanding, an attempt to provide a general-purpose property-fetching API for arbitrary data structures. If you've used a Java template engine such as Velocity or Freemarker, it would be an attempt at something similar to the dotted property access notation that they provide. Instead of code like: public String fetch(MyClass myObj) { if (myObj != null) { SomeClass path = myObj.getPath(); if (myPath != null) { AnotherClass to = myPath.getTo(); if (to != null) { String property = to.getProperty(); if (property != null) { return property; } } } } return ""; } these tools allow access the property like this: ${myObj.path.to.property} The big difference in ECMASCript is that the period is allowed as part of property identifiers. If Matt's code allowed you to, if necessary, use this instead: $prop(myObj "path~to~property", "~") I simply don't see the issue. -- Scott
From: Thomas 'PointedEars' Lahn on 12 May 2010 14:00 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Matt Kruse wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> No, by contrast you will not be able to handle property names that >>>> contain `|'. >> >>> Umm, then you just pick a different delimiter that doesn't conflict >>> with your property names. Duh. >> >> Your shortsightedness blinds you again for the possibilities that await >> you. As long as you choose string delimiters for separating parts of the >> /MemberExpression/ used to access a property, your implementation will >> not be able to deal with objects that have properties with names that >> contain those delimiters. > > While I agree with what seems to be the majority opinion that strings > with delimiters are not the best solution, I'm not sure I can buy this > objection. Matt said he was passing alternative delimiters as an > additional parameter to the call. Since the presumed use is something > like > > var xyz = $prop(document, "forms[0].foo[].value"); > > or if necessary, > > var xyz = $prop(obj, 'property|.property.|[property]', '|'); > > and not > > var xyz = $prop(obj, myStringVar); > > it's easy enough to see by inspection that the delimiter is not > included in the string. Utter nonsense. First of all, to $prop() there is exactly no difference with regard to how the value was passed. That's not only JavaScript 101, it's Programming 101. Second, without further information the first property access could be the equivalent of any of the following, with the list not making a claim to be complete: document.forms[0].foo.["[]"].value document.forms[0]["foo[]"].value document.forms["[0].foo[]"].value document["forms[0]"]["foo[]"].value document["forms[0].foo[]"].value document["forms[0]"]["foo[].value"] document["forms[0].foo[].value"] With the second approach, it needs to be clearly defined which delimiter is used if no delimiter is specified. Third, with either solution the issue remains that a property name may not contain the delimiter then, when that would not be necessary had a different approach been chosen. IOW, it is not possible to access obj["property"][".property."]["[prop|erty]"] with $prop(obj, 'property|.property.|[prop|erty]', '|') because that would access obj["property"][".property."]["[prop"]["erty]"] instead. And if you defined `[' and `]' (or something else) as delimiter for property names you would could not have property names that contained them. Or your would have to implement an escape syntax so that those characters are not considered delimiters, which would exclude those escape sequences from being part of property names. But all of this is completely unnecessary if you let the programming language provide the delimiter, i.e. arguments, Arrays, or a combination thereof. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on 12 May 2010 14:10
Thomas 'PointedEars' Lahn wrote: > Scott Sauyet wrote: >> var xyz = $prop(document, "forms[0].foo[].value"); >> [...] > > [...] without further information the first property access could be the > equivalent of any of the following, with the list not making a claim to be > complete: > > document.forms[0].foo.["[]"].value document.forms[0].foo["[]"].value > document.forms[0]["foo[]"].value > document.forms["[0].foo[]"].value > document["forms[0]"]["foo[]"].value > document["forms[0].foo[]"].value > document["forms[0]"]["foo[].value"] > document["forms[0].foo[].value"] > [...] PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |