PDA

View Full Version : getChildrenByTagName



vtswingkid
19 Feb 2007, 10:11 AM
What is the suggested new and improved replacement for this?

jack.slocum
19 Feb 2007, 10:49 AM
There are two/three options:

CompositeElementLite:

el.select('.some-class');

CompositeElement (heavier and generally should not be needed):

el.select('.some-class', true);

and then an array of DOM nodes:

el.query('.some-class');

and a single child:

el.child('div.some-class');

Obviously since these are selectors you can do much more than class queries. In general, you will want to prefix your query with tag names for the best performance, but it's not required.

Old way:


var children = el.getChildrenByClassName('foo');
for(var i = 0, len = children.length; i < len; i++){
children[i].on('click', doSomething);
}

New way:


el.select('.foo').on('click', doSomething);

jack.slocum
19 Feb 2007, 10:51 AM
By the way, not only is the new code shorter and cleaner, it will be faster (use less memory) as well. :)

SteveEisner
13 Mar 2007, 5:07 PM
Question about this code - what is the performance cost when dealing with deep trees? I have some routines which want to find direct children by class name, but I'm afraid that using el.select('.some-class') will scan the entire subtree when all I really wanted to do is look at the four nodes underneath el. And as far as I understand, there's no way to simulate "x > y" notation when the X is the root of the DomQuery? I'd love to do something like el.select('el > .child-class') or el.select('/*.child-class') - even if el is not the root of the document...

Thanks,
Steve

jon.whitcraft
13 Mar 2007, 5:13 PM
I do belive that doing a select from a given node will only look at the children of that node and below but never stray out side of that node.

SteveEisner
13 Mar 2007, 5:49 PM
Thanks - that's a great point that also relates. I was actually asking about a very deep tree, all under the same element, but there's definitely the consideration of sideways scanning as well.

Theoretical question: does DomQuery match selectors that are outside the tree? In other words, if I say el.select('body .X') - where el is some node deep in the DOM - will it match a node with class X even though the CSS query has to first match something outside the scope of the select() ?

Practical example: In my code I have built up multi-section documents which I then use DomQuery to group into tabs. So I have something like:

<div id="MyPage">
<div class="Tab"> ... lots of HTML ... </div>
<div class="Tab"> ... lots of HTML ... </div>
<div class="Tab"> ... lots of HTML ... </div>
<div class="Tab"> ... lots of HTML ... </div>
</div>
and then I do:

Ext.get('MyPage').select('.Tab').each(function(el){ ... add to a BorderLayout somewhere ... });
But I'd be perfectly happy to do

Ext.get('MyPage').select('#MyPage>.Tab').each(function(el){ ... add to a BorderLayout somewhere ... });
if it always worked?

So that's what I mean when I ask about the performance of selecting ".Tab". First, I don't really want it to match an arbitrary "Tab" class deep in the HTML. Second, I don't even want it to scan into those, I just want to look at direct children. And that's why I am missing the getChildrenByClass function.

Steve

SteveEisner
23 Mar 2007, 10:54 AM
Jack - any idea if this kind of selection will always work? (ie. when the selector correctly specifies a subnode, but some part of the selector statement refers to nodes *above* the node you're doing .select on)

jack.slocum
26 Mar 2007, 2:33 PM
As long as your element has an id (and Ext.get would generate one if it doesn't have one) this code is how I do it:

el.select('> .some-class');

SteveEisner
26 Mar 2007, 10:45 PM
Thanks Jack, that's a great idea.

I'm still curious about the cases above (would they match correctly, reliably?) but there's no hurry now that you've given me that workaround...