Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Recursive function to find a node in the DOM Date: Sun, 19 Jul 2015 12:27:06 +0200 Organization: PointedEars Software (PES) Lines: 180 Message-ID: <4029225.tIX9iqhVEp@PointedEars.de> References: <5530725.v0RXNFEj4j@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1437301836 7157 eJwFwQkBwEAIAzBNFChMzvj8S7jElcIOo9P8/LB/kk2X1Tm9L8ZCZAqJkk5qAlir0jLqPBhtENA= (19 Jul 2015 10:30:36 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Sun, 19 Jul 2015 10:30:36 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNy8kBwDAIA7CZIBjMOOHI/iO0+gvHxTvM4YaHJ0Y/ZNZVbsL13YexSwWbxRrbKWzMhG5Ebnhty18jW+YDUkYWJg== Cancel-Lock: sha1:7D5wa64tcwR+hFd5WPFue+G2vc0= X-NNTP-Posting-Host: eJwFwYEBwCAIA7CXWillnjPZ+P8EkwzTXXJaOTlbwcZZqhmJMcJqKp7+LDWB918wWMLZ5QsAMg/E Xref: csiph.com comp.lang.javascript:28453 danca (Daniele Campagna) wrote: > Il 07/15/2015 11:59 AM, Thomas 'PointedEars' Lahn ha scritto: >> document.forms[…].elements[…] and getElementsByTagName(…) exist. You do >> not need that function even for Netscape Navigator 2 (the fact aside that >> it would not work there as it is). > > The idea was to have a very generalized function. It finds whatever > in whatever , and is used in a series of web > applications I wrote, so I'm not tied to a tagName nor I use it only for > forms... See my correction. You can use the getElementsByName(…) method for that; it is available on HTML document objects in implementations of W3C DOM Level 2 HTML (since 2003) and HTML5. The getElementsByName(…) method is not available on element objects (at least not in a standards-compliant way; implementations may vary); however, the getElementsByTagName(…) method is, starting from IE/MSHTML 5.5 at the latest. That method can be called as element.getElementsByTagName("*"), and the resulting NodeList can be filtered, if you do not want to be tied to a specific “tagName” property value. If all else fails, the return value of document.getElementsByTagName("*") can be filtered. Higher Levels of the W3C DOM, implemented in recent Web layout engines, support other such methods that are more flexible, too: document.evaluate(…) for XPath queries, and document.querySelector(…) and document.querySelectorAll() for CSS queries. Also, you are reinventing the wheel. Several common libraries provide such a function, by using a query engine or otherwise. So I do not foresee many people being interested in your function. That said, I do not see why you would need this algorithm that finds an element by name in any context in the first place because there are more efficient built-in ones. The “name” attribute is only allowed for the following element types (cf. [1] and [2]): - “a” elements: It is more efficient to filter “document.links” or the return value of node.getElementsByTagName("a"). Where “document.links” is not only a NodeList but a HTMLCollection, document.links["…"] is the most efficient approach. Also, the “name” attribute is obsolete for “a” elements since HTML5, in favor of the “id” attribute which allows those “a” elements to be referred by the return value of document.getElementById(…). - “applet” elements: It is more efficient to filter document.applets or the return value of node.getElementsByTagName("applet"). Also, the “applet” element is deprecated in HTML 4, and obsolete since HTML5. - “form” elements: It is more efficient to use document.forms["…"]. - form controls: There should not be form controls in an HTML document that are not part of a form. Only an ancestor “form” element guarantees proper validation in HTML 5, and that this event works without client-side scripting everywhere. Controls of a specific form can be referred to by name with document.forms[…].elements["…"]. In most cases it is not even necessary to refer to the form by name or index because form controls have a “form” property to refer to the form they are a part of, and “this” can be used in event-handler attributes and event listeners to refer to the element object for the element that fired the event. However, in case a form control is not part of a form, document.getElementsByName("…"), document.getElementById("…"), or node.getElementsByTagName("…") suffice. Because the same name SHOULD NOT be used for different kinds of element types, such as both for an “object” element and a form control. - “frame” and “iframe” elements: It is more efficient to use window.frames["…"]. - “img” elements It is more efficient to use document.images["…"]. Also, the “name” attribute is obsolete for “img” elements since HTML5. - “map” elements: It is more efficient to filter the return value of node.getElementsByTagName("map"). - “meta” elements: It is more efficient to filter the return value of node.getElementsByTagName("meta") or, because the “name” attribute of META elements has historically been of the NAME type, there would not be more than one element with that name in the document, and document.getElementsByName("…") can be used. - “object” elements: It is more efficient to filter document.applets or the return value of node.getElementsByTagName("object"). - “param” elements: It is more efficient to filter the return value of node.getElementsByTagName("param"). [1] [2] >> If you can change the input[type="text"] into an input[type="file"], for >> security reasons the value of the control will be reset, and you cannot >> set the “value” property of an input[type="file"] for the same reason. >> So this appears to be a futile exercise (other than to test the security >> fix). > > I know of that. But it is not an exercise. The scenario here is: a user > can post a message in a [kinda of] message system. Messages can have > attachments. If the author wants to edit the message he posted, he may > want to change the text or the attachment. So he has a button "change > attachment", and the input showing the name of the actual attachment > becomes a to select another one and upload it. :-) (“Exercise” was not to be understood verbatim.) See my correction. There appears to be no point to use a read-only input[type="text"] element here if you want to support IE/MSHTML because you need to replace the element in any case. >>> One strange thing is the way recursion is implemented in javascript: I >>> did not put the "return retval" statement at first, it seems unuseful, >>> and went crazy before discovering that it is needed. >> >> There is no “javascript”. > > ECMA, ok, ECMA. There is no ECMA (anymore). There are Ecma International, and the ECMAScript Language Specification (named for historical reasons). But what matters more than the name is the fact that this specification has several *different* implementations; several of them have “JavaScript” in their name. > Of course you need a break condition to prevent infinite recursion; this > has nothing to do with what you think would be “javascript”. > > Well I only wanted to point out that in other languages (f.e. xbase, the > main language I use - to write CGI's at present -) I would have written > the very same function with no need to put a return statement there. I do not know xbase. ECMAScript is a language of the C family, so you need to return a value from a function if you want to avoid an implicit return value. The implicit return value is the “undefined” value in ECMAScript implementations. > And the proper approach here is iteration (walking the >> document tree), not recursion; because the stack size and/or nesting >> level is limited (the Google Groups archive has test results), but an >> element’s nesting level within a document tree is not. > > Yes, but all this stuff is server-side generated, so I am quite in > control of the pages (they are small in size) and I must confess that I > like very much the recursive approach - but I am aware of the stack > growth and memory consumption it causes. Above you have claimed generality for this function, and you have expressed desire to make it available to the public because of that. It fails to do that job if it does not work with any document. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.