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

This site is best viewed in a modern browser with JavaScript enabled.

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

frankvw

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.

Like so:

<p>First select your province:</p>
<select id="province" name="province" 
  onchange=ajaxRead(this.options[this.selectedIndex].value, \'city\')">
<option selected="selected" value="0">Select province</option>
<option value="1">Northern Province</option>
<option value="2">North West</option>
...
</select>

<p>Then select your city:</p>
<div id="city">
<select name="city">
<option selected="selected" value="0">Select city</option>
</select>
</div>

The ajaxRead() call retrieves correctly formatted HTML code for the entire <select> dropdown box depending on user input, e.g. like so:

<select name="city">
<option value="1">Johannesburg</option>
<option value="2">Pretoria</option>
...
</select>

The actual modifications to the contents of the <div id="city"> .. </div> are made by the following Javascript 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.

All response appreciated!!

// Frank

slaughters

That's one of the problems with the use of 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)

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)

Here is a nice write up on DOM techniques if you need it:
http://slayeroffice.com/articles/innerHTML_alternatives/

Here is an example of adding an option tag to a Select using DOM techniques:
http://www.w3schools.com/jsref/met_select_add.asp

frankvw

slaughters;1041519 wrote:
That's one of the problems with the use of 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.

slaughters;1041519 wrote:
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... :-/

slaughters;1041519 wrote:
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.

Aargh.

slaughters;1041519 wrote:
Here is a nice write up on DOM techniques if you need it:
http://slayeroffice.com/articles/innerHTML_alternatives/

Here is an example of adding an option tag to a Select using DOM techniques:
http://www.w3schools.com/jsref/met_select_add.asp

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.... :-/

// FvW

slaughters

frankvw;1041677 wrote:
...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.

BUT - according to a Microsoft support page the way you are doing it should work: http://support.microsoft.com/kb/276228

Here is a link to some code someone wrote that will take a string of <option> tags and parse them then use the DOM to create the options to an existing select:
http://elmicoxcodes.blogspot.com/2007/02/innerhtml-and-select-option-in-ie.html

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'>').

frankvw;1041677 wrote:
...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.

frankvw

slaughters;1041703 wrote:
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.

That sounds entirely plausible to me.

slaughters;1041703 wrote:
BUT - according to a Microsoft support page the way you are doing it should work: http://support.microsoft.com/kb/276228

This bug refers to IE mangling the <option>...</option> HTML code when you add it to an existing <select>...</select>. It's unrelated to the changes not appearing in the posted form data.

slaughters;1041703 wrote:
Here is a link to some code someone wrote that will take a string of <option> tags and parse them then use the DOM to create the options to an existing select:
http://elmicoxcodes.blogspot.com/2007/02/innerhtml-and-select-option-in-ie.html

I'm having a look at that right now. Thanks!

slaughters;1041703 wrote:
The Firebug pluggin for Firefox is pretty decent.

Then it deserves a test drive. Thanks for the tip!

// FvW

vlalieu

Thanks -- after reading the articles, I have switched from innerHTML to DOM and got my Joomla fabrik dynamic forms showing up the same way on Firefox and Internet Explorer!