Path: csiph.com!au2pb.net!feeder.erje.net!1.eu.feeder.erje.net!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: Wed, 12 Aug 2015 01:18:38 +0200 Organization: PointedEars Software (PES) Lines: 61 Message-ID: <4738754.gQ6MLv009L@PointedEars.de> References: <5530725.v0RXNFEj4j@PointedEars.de> <1885256.KGaLaWtVka@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 1439335335 3634 eJwNycEBwCAIA8CVBEIs4yA1+4/Q3vcyaJwNJpFKsbVsq9Sww/+atTyEB07v6bp3Xq3wIEbnAxbqESs= (11 Aug 2015 23:22:15 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 11 Aug 2015 23:22:15 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwFwYkBwCAIA8CV5AmYcTSV/UfoHaKs1FmoxGBalUR+Yz5nbTB4gy2H/FE00o+tZ18/KQ50a3rTG+VN/T+ZFPc= Cancel-Lock: sha1:GjfpMIkG7ihs3oNnwC4Rka7zsFk= X-NNTP-Posting-Host: eJwFwQkBwDAIA0BLpINA5ZTPv4Td2UewXGlUW1tWGTGKOBt3akS3L0ZC0KbIzuPLlBf1vPsHHhkRjg== Xref: csiph.com comp.lang.javascript:28517 Christoph M. Becker wrote: > On 08.08.2015 at 09:33, Thomas 'PointedEars' Lahn wrote: >> […] you can do an iterative "user-land" walk of the document tree as >> well; for example: >> >> grandparent ----------------. >> ,-- grandparent.firstChild <--' >> `---> grandparent.firstChild.firstChild ---------------. >> ,----- grandparent.firstChild.firstChild.nextSibling <--' >> `--> >> grandparent.firstChild.firstChild.nextSibling.parentNode.nextSibling >> --> END. >> >> (The algorithm and implementation are left as an exercise to the reader.) > > Seems to be rather trivial: > > grandparent.firstChild.nextSibling That is neither an algorithm nor an implementation :) > I don't know, however, in which way this would help to find a *certain* > *node* somewhere in the DOM (which seems to be the topic of this thread, > if I'm not mistaken). To do this, it is necessary to inspect all DOM > nodes (at least until the node which is looked for is found). Yes, in that regard not at all dissimilar to a recursive approach. > How can this be done with an iterative algorithm? You are the reader, you figure it out :-p > Of course, by using an explicit stack (which would be stored on the heap), No, the whole idea of an iterative approach is not to need a stack. Hint: node.lastChild.nextSibling === null. > Then again, I can hardly imagine a recursive tree searching algorithm > running out of machine stack space on a reasonably sized DOM tree on > somewhat contempory browsers/machines. What is your point? If things were only as you wish them to be, if there were only “reasonably sized DOM trees” and “somewhat contemporary browsers/machines” in the wild, we would not have this discussion. Either you are a defensive – and if I may say so, *logical* – programmer, considering the contingency that things are not necessarily, and in few cases are, as you wish them to be, or you are not. I do not know about you, but I rather have slow code than code that breaks down when attempting to solved a problem. JFTR: I would not use either an explicitly iterative nor an explicitly recursive approach as my preferred choice. But the solution sought for was to be used as a fallback only, and *then* I choose the iterative approach because it cannot fail. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.