By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,636 Members | 1,189 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,636 IT Pros & Developers. It's quick & easy.

hiding/showing: right way?

P: n/a
I have a folder/file tree that is dynamically generated from an xml
file. The way I've written it seems to work. Since I'm a fairly novice
javascript programmer, I'm concerned that there may be a hidden
downside to coding this way vs. hiding/showing using style.visibility.

My tree starts with only the top level folders showing. When the xml
for the tree loads, I have a recursive function that creates subtrees
for each folder, then saves them as a property of that folder.

buildTree: function( root, offset )
{
var curNode = root;
var myIndent = 20;
var myHeight = 22;

if( offset == null )
{
myIndent = 2;
}
else
{
myIndent += offset;
}

var spacer = "";
for( var i = 0; i < myIndent;i++ )
{
spacer += "-";
}

var elem = document.createElement( "div" );
elem.style.top = 0;

if( curNode.nodeName == "folder" )
{
elem.id = "FolderElement";

var children = curNode.childNodes;
var subTreeItems = new Array( );
for( var i = 0; i < children.length; i++ )
{
if( children[i].nodeType == "1" )
{
var newChild = this.buildTree( children[i], myIndent );
subTreeItems.push( newChild );
}
}

var folderName = curNode.attributes[0].nodeValue;
var isEmpty = subTreeItems.length > 0 ? false : true ;
var line = this.makeFolderLine(folderName , myHeight, myIndent,
isEmpty );

elem.appendChild( line );

Event.observe( line, "mouseup", this.__neh_toggleFolder_closure,
false);

elem["subTreeData"]= subTreeItems;
}
else if( curNode.nodeName == "item" )
{
elem.id = "ItemElement";
elem.className = "item";
var itemObj = new this.ItemObject( curNode );
var line = this.makeItemLine( itemObj, myHeight, myIndent );

elem.appendChild( line );

Event.observe( line, "mousedown", this.__neh_selectItemDown_closure,
false);

}

return elem;
},
When the user opens a folder, the subtree elements are appended.

Are there any dangers/concerns using this method?

(Warning for the anti-library folks -- I am using the library
prototype.js to add and remove event listeners)

Thanks,

Cathy

Oct 14 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
The only problem I see with it is that it would assign multiple
elements with the same ID attribute. This is a HUGE (X)HTML no no. You
could set elem.id to elem.className (or elem.className =
elem.className + newClassName) instead.

But other than that the code seems sound. I might, however, point you
to http://gazingus.org/html/DOM-Scripte...Revisited.html, which
has a hierarchal tree script that is simply attached to a list. That
means you would simply have to use basic DOM functions (or even
innerHTML) to modify the tree contents and ignore the heavy lifting
altogether. This would also have the advantage of being more usable to
people with older browsers or JavaScript turned off.

Oct 17 '05 #2

P: n/a
Joshie Surber wrote:
The only problem I see with it is that it would assign multiple
elements with the same ID attribute. This is a HUGE (X)HTML no no. You
could set elem.id to elem.className (or elem.className =
elem.className + newClassName) instead.

Thanks Joshie. I've noticed that using elem.className is too slow,
since I have multiple class names and have to use a regex to extract
the proper one. But point taken about unique ids. I'll probablly just
add a custom property to indicate folderline vs. fileline.
But other than that the code seems sound. I might, however, point you
to http://gazingus.org/html/DOM-Scripte...Revisited.html, which
has a hierarchal tree script that is simply attached to a list. That
means you would simply have to use basic DOM functions (or even
innerHTML) to modify the tree contents and ignore the heavy lifting
altogether.
Interesting ref. It is always nice to see how others do things. At this
point, though, the tree structure is a small part of a lot of code, and
I don't want to switch it out and risk breaking stuff.
This would also have the advantage of being more usable to
people with older browsers or JavaScript turned off.


This is for an app where it is okay to have firm browser reqs. I'm
doing a lot of feature sniffing and if the features aren't found, the
app won't work.

BTW = if you are using Google Groups, click the "options" link to reply
with the original message quoted.

Oct 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.