Form fields missing from submitted data after having been modified using innerHTML

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

Form fields missing from submitted data after having been modified using innerHTML

Can anyone shed some light on the following? Because I'm totally stumped.

I have a basic HTML form. I am using some AJAX-ish scripting to modify a <select> dropdown box depending on user input. E.g. after the user selects a province, the <select> below it is populated with cities in _that_ province.

The actual modifications to the contents of the <div id="city"> .. </div> are made by the following Javascript code:

Code:

document.getElementById(obj).innerHTML = data;

in which obj refers to the div, and data to the retrieved HTML code.

This all works as expected, and all is fine until I start processing the submitted form data. When I examine the submitted data, I find that the modified input (i.e. 'city') is missing from the submitted data.

If I do not run the above javascript code to update the div's innerHTML, all is fine, and the input (with its only option which is set to a value of 0) is submitted correctly. However as soon as I do modifiy the div's innerHTML, thereby replacing the <select>...</select> section with the code retrieved by the ajaxRead() call, it disappears from the submitted form data.

The code retrieved by ajaxRead() is properly formatted HTML, and using the 'view generated source' option in the Firefox WebDeveloper toolbar reflects this.

Update: I experience this behavior both in Firefox 3.5 and IE7.

Is there anyone who can point me into the right direction? I've been banging my head against the wall for two days now and it's starting to feel a bit sore.

It does not properly create the html objects in the DOM tree. So it's great for easy format changes, messages, ect. but you can't manipulate the objects created within it. (at least there is no guarantee that you can)

I'm kind of surprised it will not recognize the new form field, but it looks like in this case you will be stuck having to add/remove the select option tags through DOM manipulation (a bit of a pain compared to innerHTML)

It does not properly create the html objects in the DOM tree. So it's great for easy format changes, messages, ect. but you can't manipulate the objects created within it. (at least there is no guarantee that you can)

From some late-night-reading-up I did on it, I get the feeling that innerHTML() inserts its data in the browser's process chain after the form data is interpreted but before the page is rendered. I may be wrong, of course... but if I am not, this seems a pretty kludgy way to do it. On the other hand, given the implementation issues that have been a mainstay of web development since the Browser Wars of the 1990's, it wouldn't be unheard of.

Originally Posted by slaughters

I'm kind of surprised it will not recognize the new form field,

What surprised me more is that the field will be part of the submitted data, _until_ innerHTML has touched it, at which point it disappears from the submitted data. I could understand the changes not showing up, but the element disappearing just because innerHTML() has been applied to it at all is something I cannot get my head wrapped around. If innerHTML() does manage to affect the submitted form data, why doesn't it do it properly then? That makes no sense to me. Anyway. The fact is that it does behave that way, so there's little point in moaning about it... :-/

Originally Posted by slaughters

but it looks like in this case you will be stuck having to add/remove the select option tags through DOM manipulation (a bit of a pain compared to innerHTML)

More than a bit - the back-end PHP code that retrieves the data from mySQL passes that data as formatted HTML in a string, which means I can use xmlObj.open() to retrieve it via HTTP, and innerHTML() will be able to handle it without any further parsing. Using DOM involves a series of function calls that require each component of the element to be passed to them separately, which either means I cannot use the usual HTTP request to retrieve the data (and I am not sure there is an alternative) or I have to parse the data in Javascript (ouch!) before further processing.

I definitely do need it - my Javascript skills are limited. Which stems in no small part from the lack of a good development environment, BTW. In the 1990's I used Borland's Integrated Development Environment, and it only took me one week to learn Pascal and two to learn C using that. And now, well into the 21st century, debugging Javascript is on par with the level of primitiveness (primitivity?) of BASIC in 1982. But I digress.

Thanks, Stan - it looks like I have a lot of reading up and recoding to do.... :-/

...What surprised me more is that the field will be part of the submitted data, _until_ innerHTML has touched it, at which point it disappears...

This makes sense when you think about it. What happened is that the form element exists on the web page when the page loads. The innerHTML assignment then destroys it and a brand new element is created that simply has the same name as the old one. It's just created in a way that does not allow it to function properly.

Call it with two parameters: the select you would like to put options into ex- document.getElementById('formSelect'), and the string of options you would like inserted into the select statement ('<option>Option 1</option'>').

Originally Posted by frankvw

...debugging Javascript is on par with the level of primitiveness (primitivity?) of BASIC in 1982. But I digress.

The Firebug pluggin for Firefox is pretty decent. It's not really an IDE, but it lets you view elements on the page as they look *after* they have been manipulated on the client side (inspect element) and to an extent lets you modify HTML, CSS and Javscript values on the page where you can get real time dynamic feed back (all from within a browser pluggin)

IE 8 has something similar built into it called the Web Developers toolbar. Simply hit F12 to bring it up.

This makes sense when you think about it. What happened is that the form element exists on the web page when the page loads. The innerHTML assignment then destroys it and a brand new element is created that simply has the same name as the old one. It's just created in a way that does not allow it to function properly.