innerHTML / Appendchild question

[Nicolas Van Lancker]

Hi folks;

I have this webpage, allowing users to insert multiple records in one post
into the database.

Because I don't know the exact number of records they want to add, I created
a little javascript
that adds a new line with HTML inputboxes and lists to the form if they
press a button.

My first version of the script used innerHTML to add the new line of HTML
It works great in IE. But in NS/Mozilla each time I add new items the
already existing textboxes
(filled in) and already existing listboxes (with selected items) 'loose'
their data or selections.

var newhtmltoadd = '<input type=....' // The new line of html to add.
document.newlin e.innerHTML = document.newlin e.innerHTML + newhtmltoadd;

So I figured out this innerHTML way might not be the most fancy solution to
my problem and
I tried by the using the more DOM approach : appendChild

But the problem remains the same. Works fine in IE, NS/Mozilla reinitialise
my exisiting form objects in the area where I append.

Here is my appendChild code

var listbox=documen t.createElement ('select');
listbox.setAttr ibute("name","F kRelie-New-"+id);
listbox.setAttr ibute("class"," defaultlistbox" );

//fill listbox with data from similar existing listbox

for(var
i=0;i<document. getElementById( 'FkRelie-New-1').length;i++) {
listbox.options[i]=new
Option(document .getElementById ("FkRelie-New-1").options[i].text);
listbox.options[i].value=new
Option(document .getElementById ("FkRelie-New-1").options[i].value);
}

document.getEle mentById('NewPt Left').appendCh ild(listbox);

Now. Is this a NS/Mozilla problem or am I doing something wrong?
How can I preserve state from my already exising form objects when adding
new ones in NS/Mozilla?

Thanx in advance,

Nicolas

[Richard Cornford]

Nicolas Van Lancker wrote:
<snip>

Here is my appendChild code

var listbox=documen t.createElement ('select');
listbox.setAttr ibute("name","F kRelie-New-"+id); ^^^^ ^^^^^^^^^^^^
The implication of this attribute creation is that the existing SELECT
elements also have name attributes taking the form - FkRelie-New-1 -,
but the fact that you are not setting an ID attribute at this point
suggest that the existing SELECT elements do not have corresponding ID
attributes.

Incidentally, using - setAttribute - is generally less successful than
assigning values directly to the corresponding W3C HTML/Core DOM
specified object properties.

listbox.setAttr ibute("class"," defaultlistbox" );

//fill listbox with data from similar existing listbox

for(var
i=0;i<document. getElementById( 'FkRelie-New-1').length;i++) { ^^
But here you are using the - getElementById - method to acquire a
reference to an existing select element. In a normal context (no custom
DTD) the "Id" at the end of - getElementById - means what it says; only
elements with ID attributes should be expected to be retrievable using
that method. The IE implementation of - getElementById - is buggy and
will return references to elements that only have corresponding NAME
attributes (because it is optimised to make the reference in a
collection that contains properties corresponding with the NAME
attributes of elements in addition to ID attributes) but no other
browsers are known to exhibit that flaw.

Generally, the retrieval of references to form control within HTML pages
is better done using the W3C HTML DOM specified - document.forms - and -
elements - collections, which make controls with NAME attributes
directly available (along with elements that have ID attributes) as
named properties.
listbox.options[i]=new
Option(document .getElementById ("FkRelie-New-1").options[i].text);
listbox.options[i].value=new
Option(document .getElementById ("FkRelie-New-1").options[i].value);
}
Now that is a little odd; you create and assign an Option element and
then immediately create a second Option element and use it to replace
the first.

The repeated element retrieval for the same element is extremely
inefficient, it would make more sense to retrieve the reference to the
element once and assign it to a local variable. Which would also allow
you to verify that the retrieval attempt was successful before acting on
what you are otherwise assuming is an object (but may be null under some
circumstances).

<snip> Is this a NS/Mozilla problem or am I doing something wrong?

<snip>

Mozilla, and all other Gecko based browsers, are extremely good at what
you are attempting to do here (better than IE in some respects), so if
it isn't working it is going to be your coding that is at fault.

Richard.