SUBJECT: Can't get script to work in Firefox

M

mattrapoport

Hello - I am kinda new to the HTML DOM so I apologize in advance for my
ignorance.

I have a table made from divs. I am trying to write a script that
appends a new row to the table (by cloning the last row) and then
adding some text to the fields in that row. My script works perfectly
in IE but not even close in Firefox. Here's my HTML ...

HTML:

<div name='test' id='attachTable'>
<div name='first'>
<div class='iw_fieldBox attach_name iw_fieldBottom'>
<div class='attachName' name='attachName'>&nbsp;</div>
</div>
<div class='iw_fieldBox attach_desc_x iw_fieldRightBottom'>
<div class='attachDesc' name='attachDesc'>&nbsp;</div>
<div class='iw_xSign'><img alt='' src='../images/x.jpg'></div>
</div>
</div>
</div>

The "attachTable" div contains the entire table. The div named "first"
contains the first and only row. There are 2 fields in each row -
attachName & attachDesc - I want to change the text of these fields in
the newly created row. Here's my js ...

function appendRow(tableName, contents)
{
// FIND THE TABLE IN WHICH TO APPEND THE ROW
oTable = document.getElementById(tableName);

// CLONE THE LAST NODE (IN THIS INSTANCE IT IS THE DIV NAMED "FIRST")
oNewRow = oTable.lastChild.cloneNode(true);

// ERASE THE NAME
oNewRow.name = '';

// CHANGE THE BORDER STYLE ON ALL CELLS
if (oNewRow.hasChildNodes)
{
for (var i = 0; i < oNewRow.childNodes.length; i++)
{
oNewRow.childNodes.className += " eraseTopBorder";
}
}

// THE CONTENTS VARIABLE CONTAINS A STRING OF ARGUMENTS
// IN THE FORMAT fieldName!q=q!fieldValue;q*q;fieldName!q=q!fieldValue
....
// THESE ARGUMENTS ARE USED TO CHANGE THE TEXT OF THE ROW
contentArray = contents.split(";q*q;");
for (var i = 0; i < contentArray.length; i++)
{
stringSplit = contentArray.split("!q=q!")
if (stringSplit.length == 2)
{

// THIS CALLS A RECURSIVE FUNCTION TO FIND THE FIELD AND THEN
// REPLACE ITS TEXT
replaceNodeData(oNewRow, stringSplit[0], stringSplit[1]);
}
}

// APPEND THE NEW NODE TO THE END OF THE TABLE
oTable.appendChild(oNewRow);
return (oNewRow);
}

function replaceNodeData(node, node_Name, node_Value)
{

// THIS IS MY RECURSIVE FUNCTION - IT'S MEANT TO WALK THE TREE
// UNDERNEATH MY NEW ROW AND FIND THE FIELDS BY NAME
for (var j = 0; j < node.childNodes.length; j++)
{
replaceNodeData(node.childNodes[j], node_Name, node_Value);
}

// IF THE NODE'S NAME MATCHES THE ARGUMENT, THEN THE TEXT IS CHANGED
// NOTE THAT THE TEXT IS CHANGED ON THE CHILDNODE BECAUSE I BELIEVE THE
// TEXT IS A TEXT ELEMENT CONSIDERED UNDERNEATH ITS DIV.
if (node.name == node_Name)
{
node.firstChild.data = node_Value;
}
}


As I said, it works perfectly in IE. In FireFox it fails miserably. I
can't seem to find a function that reads the name of the DIV. In IE
it's just node.name. There's also node.nodeName and node.tagName. But
those just giv the name of the node (e.g. "DIV").

Also, the recursive function is not recursive in FireFox because it's
not walking the tree. It's like it starts at the last node. It's very
strange.

Any help would be greatly appreciated.

Thanks,

Matt
 
M

mattrapoport

Matt said:

I find that I have better control of table / cells.

Thanks for pointing that out! I've noticed however that my function
fails long before that. It doesn't appear to be the recursive function
that is causing the problem. As I test, I checked the number of
children in oTable. As you can see from the HTML, the div clearly has
children (oTable is the "attachTable" DIV). Firefox keeps telling me
that oTable has no children. I don't understand that???

- Matt
 
R

Richard Cornford

I find that I have better control of table / cells.


Thanks for pointing that out! I've noticed however that
my function fails long before that. It doesn't appear to
be the recursive function that is causing the problem.
As I test, I checked the number of children in oTable.
As you can see from the HTML, the div clearly has children
(oTable is the "attachTable" DIV). Firefox keeps telling me
that oTable has no children. I don't understand that???

As you have not posted any code that calls your - appendRow - function,
and it is the arguments to that call that determines what - oTable =
document.getElementById(tableName); - results in (along with the context
of that call), you are the only person in a position to speculate about
what the value of - oTable - will be at any time. It doesn't appear to
be the DIV that you think it should be, but we cannot tell what it may
be from what you have posted.

Generally, creating and posting a cut-down test-case that demonstrates
the phenomenon in isolation is your best cause of action. We can then
consider what that code does, run it, read the actual error messages,
and possibly apply tests that will be discriminating in determining what
it actually does do.

Positing fragments rarely solves problems. People can only point out
reasons why the totality cannot work, such as Matt did, and to which I
would add that your unconditional interest in - lastChild - nodes is
likely to fall foul of Gecko browser's representing non-significant
white space as text nodes in the DOM.
 
M

mattrapoport

Richard said:
As you have not posted any code that calls your - appendRow - function,
and it is the arguments to that call that determines what - oTable =
document.getElementById(tableName); - results in (along with the context
of that call), you are the only person in a position to speculate about
what the value of - oTable - will be at any time. It doesn't appear to
be the DIV that you think it should be, but we cannot tell what it may
be from what you have posted.

Generally, creating and posting a cut-down test-case that demonstrates
the phenomenon in isolation is your best cause of action. We can then
consider what that code does, run it, read the actual error messages,
and possibly apply tests that will be discriminating in determining what
it actually does do.

Positing fragments rarely solves problems. People can only point out
reasons why the totality cannot work, such as Matt did, and to which I
would add that your unconditional interest in - lastChild - nodes is
likely to fall foul of Gecko browser's representing non-significant
white space as text nodes in the DOM.


Thank you Richard. I have taken your advice and created a simplified
scenario. Same HTML as above but here's the new test function:

function test(tableName)
{
oTable = document.getElementById(tableName);
alert(oTable.childNodes.length);
alert(oTable.children.length);
}

the caller is this:

test("attachTable");

IE alerts "1", "1" - which is what I had hoped for since there is only
1 row in the table.
FF alert "3" - just once - I'm not sure why the children.length alert
fails. I'm also not sure why it is counting 3 children (unless it's
the whitespace problem that you mentioned above).

Maybe the question I should be asking is - does anyone have a script
that can walk the DOM from a specific node down (and that works in FF)?

Thank you in advance.

- Matt
 
R

Richard Cornford

Richard Cornford wrote:
Thank you Richard. I have taken your advice and created a
simplified scenario.

My advice was not to simplify the scenario, it was to create a cut-down
test case and post that.
Same HTML as above

There is no meaning to 'above' on Usenet, unless you are referring to
the contents of your current post. Newsreader software is far too
flexible in how it may present posts (I have more than 256+ layout
permutations where your 'above' would be true of 8 or so).
but here's the new
test function:

function test(tableName)
{
oTable = document.getElementById(tableName);
alert(oTable.childNodes.length);
alert(oTable.children.length);
}

the caller is this:

test("attachTable");

IE alerts "1", "1" - which is what I had hoped for since
there is only 1 row in the table.
FF alert "3" - just once - I'm not sure why the
children.length alert fails.

The - children - collection of Elements is a Microsoft proprietary
feature that is not supported by many other browsers.
I'm also not sure why it is counting 3 children (unless
it's the whitespace problem that you mentioned above).

It is the white space being represented by text nodes, but it is not a
problem as DOMs may include such white space or not, depending on the
parser or its configuration. Because they may be there it is necessary
to code in a way that accommodates them (such as working back through
previousSibling nodes when the lastChild turns out to be a text node,
until an Element node is found).
Maybe the question I should be asking is - does anyone
have a script that can walk the DOM from a specific node
down (and that works in FF)?

Not really, that answer would be 'yes'.

Richard.
 
L

Laurent Bugnion

Hi,

Thank you Richard. I have taken your advice and created a simplified
scenario. Same HTML as above but here's the new test function:

function test(tableName)
{
oTable = document.getElementById(tableName);
alert(oTable.childNodes.length);
alert(oTable.children.length);
}

the caller is this:

test("attachTable");

IE alerts "1", "1" - which is what I had hoped for since there is only
1 row in the table.
FF alert "3" - just once - I'm not sure why the children.length alert
fails. I'm also not sure why it is counting 3 children (unless it's
the whitespace problem that you mentioned above).

Maybe the question I should be asking is - does anyone have a script
that can walk the DOM from a specific node down (and that works in FF)?

Thank you in advance.

- Matt

That's *the* typical different between Firefox and IE when browsing the
DOM: Firefox counts carriage-returns as a text node, but IE ignores
them. That's why your childNodes collection has 3 nodes in Firefox and
only 1 in IE.

Since text nodes don't have an ID, you could use this kind of code:

for ( var index = 0; index < oTable.childNodes.length; index++ )
{
if ( !oTable.childNodes[ index ].id )
{
continue;
}
// Process row
}

Note however that the check might need to be more "solid" than that...

HTH,
Laurent
 
M

mattrapoport

Laurent said:
Hi,

Thank you Richard. I have taken your advice and created a simplified
scenario. Same HTML as above but here's the new test function:

function test(tableName)
{
oTable = document.getElementById(tableName);
alert(oTable.childNodes.length);
alert(oTable.children.length);
}

the caller is this:

test("attachTable");

IE alerts "1", "1" - which is what I had hoped for since there is only
1 row in the table.
FF alert "3" - just once - I'm not sure why the children.length alert
fails. I'm also not sure why it is counting 3 children (unless it's
the whitespace problem that you mentioned above).

Maybe the question I should be asking is - does anyone have a script
that can walk the DOM from a specific node down (and that works in FF)?

Thank you in advance.

- Matt

That's *the* typical different between Firefox and IE when browsing the
DOM: Firefox counts carriage-returns as a text node, but IE ignores
them. That's why your childNodes collection has 3 nodes in Firefox and
only 1 in IE.

Since text nodes don't have an ID, you could use this kind of code:

for ( var index = 0; index < oTable.childNodes.length; index++ )
{
if ( !oTable.childNodes[ index ].id )
{
continue;
}
// Process row
}

Note however that the check might need to be more "solid" than that...

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch


Thanks so much Laurent for your advice. I wasn't aware of the
whitespace difference until Richard mentioned it. And thank you also
for your sample code .. I think it will start me on the right track.

- Matt
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top