<script>
function changeContent(tablecell)
{
//alert(tablecell.firstChild.nodeValue);
/* For readability, don't use the same string delimiter as you need inside the string if you
* can avoid it: "name=\"value\"" is a lot harder to read than 'name="value"'.
*/
/* First time, tablecell.innerHTML is whatever is written in the tablecell. This is
* by CHANCE the same as tablecell.firstNode.nodeValue, since the nodeValue of a
* textNode is the text of the textNode (same for CDATA and for comment, and for attributes
* its their attribute value).
* The second time around, tableCell.firstChild is an input element, which always has
* a nodeValue of null (same as any other element, as well as for Document, DocumentFragment
* etc).
* The second time around, you will set the html code of the tablecell to be an input element
* which has the html code for the previous html element as its value. Most likely not
* what you want.
*/
tablecell.innerHTML = '<input type=text name=newname onblur="javascript:submitNewName(this);" value="'+tablecell.innerHTML+'>';
tablecell.firstChild.focus();
}
function submitNewName(textfield)
{
/* the textfield's parent node is the element containing the textfield element.
* Thus, innerHTML of the parent, is at least the textfield (and possibly more since
* the parent in theory could contain more elements). Thus, here you set the html code
* to be the value of the text field, which in turns is exactly the reverse as you did
* in the previous function.
* Thus, you may get whtat you want in the end, but why first do something and then undo it?
*/
textfield.parentNode.innerHTML= textfield.value;
newvalue = textfield.value;
alert(newvalue);
}
</script>
Thoughts: If you want to edit an input of type text, why don't you start with table cells containing inputs of type text? The good thing is that they are editable to begin with and doesn't require anything.
If you wish to be able to send them to the server using javascript, why not add a button after each which calls a function to send the data using XHR? Moreover, you can set an update event handler for the input elements to update any other data which is dependent on the contents of the editable input element. If the hidden elements you speak about do NOT depend on the data in the visible element, then why have them there are at all?
Also note that there is (or at least was) issues with differences in implementations of innerHTML across different browsers. Use jQuery instead and you are certain that you use a consisten implementation.
Finally you should validate your html markup to make certain its valid (it isn't): http://validator.w3.org
- There is no "language" attribute for the script element
- For elements that can have a language attribute, it can never take the value "javascript"
- table elements can contain optional caption followed by 0+ colgroup followed by optional thead followed by optional tfoot, followed by EITHER 0+ tbody elements or 1+ tr elements. Thus, you can have either <table><tbody><tr>...</table>, or you can have <table><tr>...</table>. Between table and the first of these, you may have the other stuff listed here, but NEVER anything else (such as a form element).
- you can't move the form inside the tr (they also have restrictions, all elements do).
- You can move the form inside the td, but be aware that a form isn't allowed to (directly) contain inline elements.
Also note that when you submit your data to the server, you will have no idea where it comes from. You will see newname="somevalue" and submit="submit", no matter what submit is pressed. That is, somevalue may change, but which cell does it concern?
Start by fixing your issues, and when you're done with that you might not have a problem continuing with the rest. If you do, feel free to come back and ask more questions.