Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #28453
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: Recursive function to find a node in the DOM |
| Date | 2015-07-19 12:27 +0200 |
| Organization | PointedEars Software (PES) |
| Message-ID | <4029225.tIX9iqhVEp@PointedEars.de> (permalink) |
| References | <mo53os$am9$1@dont-email.me> <5530725.v0RXNFEj4j@PointedEars.de> <mo5gf4$l2m$1@dont-email.me> |
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
> <name> in whatever <container>, 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").
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-85113862>
- “param” elements:
It is more efficient to filter the return value of
node.getElementsByTagName("param").
[1] <http://www.w3.org/TR/1999/REC-html401-19991224/index/attributes.html>
[2] <http://www.w3.org/TR/2014/REC-html5-20141028//index.html#attributes-1>
>> 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 <file> 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: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-15 09:59 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-15 11:59 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-15 12:03 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-15 13:36 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-19 12:27 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-19 12:34 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-21 12:08 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-25 14:11 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-25 21:22 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-27 16:12 +0200
Re: Recursive function to find a node in the DOM "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-08-08 04:50 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-08-08 09:33 +0200
Re: Recursive function to find a node in the DOM "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-08-12 00:48 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-08-12 01:18 +0200
Re: Recursive function to find a node in the DOM "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-08-13 23:26 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-08-16 08:48 +0200
Re: Recursive function to find a node in the DOM "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-08-20 02:11 +0200
Re: Recursive function to find a node in the DOM Scott Sauyet <scott.sauyet@gmail.com> - 2015-07-18 15:59 -0700
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-21 12:30 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-21 13:53 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-21 14:51 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-21 16:05 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-21 20:35 +0200
Re: Recursive function to find a node in the DOM Scott Sauyet <scott.sauyet@gmail.com> - 2015-07-30 22:10 -0700
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-08-06 10:07 +0200
Re: Recursive function to find a node in the DOM Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-08-06 20:15 +0200
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-08-08 01:21 +0200
Re: Recursive function to find a node in the DOM Scott Sauyet <scott.sauyet@gmail.com> - 2015-07-30 22:09 -0700
Re: Recursive function to find a node in the DOM Denis McMahon <denismfmcmahon@gmail.com> - 2015-07-29 03:04 +0000
Re: Recursive function to find a node in the DOM "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-08-06 10:20 +0200
csiph-web