PDA

View Full Version : Need help creating/submitting simple form with Javascript.



jlizarraga
03-12-2009, 11:49 PM
Hi all,

Apparently I'm going about creating a form with JS the wrong way, because I get strange results in both FF3 and IE6. I'm thinking it's probably something simple that I'm overlooking, but this issue has some back story so stick around if you're a trooper. :)

Using Niceforms (http://www.emblematiq.com/projects/niceforms/), I have created a nifty dynamic form (http://www.autofusion.com/development/josh/demos/service/index-dd.html) for scheduling a service appointment at a car dealership. The current service form that we use does not have areas to tell the dealer exactly what type of service your car needs, and so similarly our CGI script that processes service forms is not prepared to handle these new fields. Additionally, the new service form makes use of checkbox groups, and the CGI is not prepared to handle them.

In case you missed it: http://www.autofusion.com/development/josh/demos/service/index-dd.html

Because of these limitations of the CGI script, my solution was to simply create a form element from JS that is compatible with the CGI, insert text inputs for the checkboxes (example: <input type="text" name="someGroup" value="checked1, checked2, etc"), and insert any new fields into the comments section. Then the JS-created form is appended to document.body (Firefox and IE won't submit a form that only exists in the DOM, Safari/Opera/Chrome all will) and submitted via form.submit() instead of the one that was actually filled out. Note that I'm using DOM methods and no innerHTML to achieve this.

Sounds simple enough, but the JS-created form has some bizarre problems. In IE6, only <input> and <textarea> make it through, and ALL attributes are lost. Similarly, in FF3, only <input> and <textarea> make it to the HTML when the form is appended, and they loose their "value" attribute, except for hidden inputs which for some reason are the only form control not adversely affected. Just to make it weirder and more frustrating, Firebug reports that the JS-created form does indeed have all of the form controls (with their correct attributes/properties such as the missing "value"), but the HTML does not reflect this.

I'm stumped! :confused: I know rewriting the CGI is probably the best bet, but I have to work with what I've been given.

Any help greatly appreciated! Thanks for reading this far, at least.

The JS file in question is:

http://www.autofusion.com/development/josh/demos/service/service-dd.js

Lines 648 to 755 - It's the YAHOO.ssf.submitForm() function.

EDIT: Sorry, the only controls coming through being <input> and <textarea> is correct. I forgot that I was converting <select> elements to text inputs along with the checkboxes.

jscheuer1
03-13-2009, 07:33 AM
There is a 'trick' that often works with DOM created elements when you are having trouble getting the attributes you want recognized properly for various uses. That's to use the setAttribute() method. To be extra sure that this will work as intended do it like so:


el.setAttribute('attribute_name', 'attribute_value', 0);

The reason for the added 0 at the end is for IE, which (when you use this 0 parameter) will set the attribute regardless of whether or not it sees any differences between upper and lower case letters in the attribute name as somehow significant. All others ignore it and wouldn't require it anyway. Now, this may or may not help, but it has a good chance because when you set an element's attribute using the more ordinary:


el.attribute_name = 'value';

convention, sometimes the end result is simply the setting of a property of the element as a script object, not as a DOM element, which is what it sounds like is happening here. Using setAttribute() usually overcomes this problem.

jlizarraga
03-13-2009, 05:09 PM
sometimes the end result is simply the setting of a property of the element as a script object, not as a DOM element, which is what it sounds like is happening here.

I think you hit the nail on the head! That would explain why Firebug shows the values, but they aren't bold like form control values usually are in Firebug.

Thanks so much John. I will let you know how it works out.

Question: Is it better to be safe and always use setAttribute? Is it better for performance to use the "more ordinary convention" when it doesn't screw up like this?

Another question: What about the other way around? If I create a form control that hasn't been appended to the document yet and use setAttribute on it, can I safely access those properties later with el.attribute_name, or should I use getAttribute?

EDIT: Found some more info - At least in Firefox 3, once you've used el.setAttribute("attr", "value", 0), it's NOT safe to add to it like so:

for(var i=0; i<something.length; i++){
el.attr += "additional string information to add to value";
}

Your form control will have the original value supplied by setAttribute, and Firebug will report that .attr is a script object property with the correct value while completely losing track of the setAttribute-supplied value, even though it's staring you in the face in the HTML. :P

jscheuer1
03-13-2009, 05:56 PM
It is more efficient to use el.whatever = 'something', if your code works.

el.attr is a jQuery thing and in your post isn't used correctly, I'm not sure how they implement it. If it messes up your script, avoid it. Or you might have just been saving time and meant:


el.attribute_name += 'additional_attribute_value';

Once again, if it's causing a problem, use:


el.setAttribute('attribute_name', el.getAttribute('attribute_name', 0) + 'additional_attribute_value', 0);

jlizarraga
03-13-2009, 06:04 PM
Oh I don't know much about jQuery - yeah it was just a shortened example of what you posted.

I had to use your latest example to add to the attribute value.

And I can now confirm the following gotcha in FF3 in this situation:


el.setAttribute("attribute_name", "attribute_value", 0)
alert(el.attribute_name); // alerts ""
alert(el.getAttribute("attribute_name", 0)) // alerts "attribute_value"

jscheuer1
03-13-2009, 06:16 PM
I don't think it's supposed to work like that, but if it does - do what works. I've got a script where I do:


el.id = '';
el.removeAttribute('id', 0);

because the id was originally hard coded, and I want to remove all trace of it, just so things look as I intend if the element is inspected by designers working with the code. Using only the first method gives it an empty string for id in the DOM inspectors of various browsers. Adding the second method wipes the id out completely in those browsers that have DOM inspectors. I keep the first method because I'm not sure what older browsers will do, and I don't want to test in all of them.

Something else you should be aware of, if an element already has the desired attributes or most of them, and is the right tag name, just cloning it can save a lot of time.

jlizarraga
03-24-2009, 09:52 PM
Update for any Googlers: Beware the "value" property for TEXTAREA elements. This value will show the contents of the textarea in all browsers, but setting it via setAttribute or textarea.value = 'some value'; will not work in all browsers. Use instead:

theTextarea.appendChild(document.createTextNode('blah'));

jscheuer1
03-25-2009, 12:45 AM
Update for any Googlers: Beware the "value" property for TEXTAREA elements. This value will show the contents of the textarea in all browsers, but setting it via setAttribute or textarea.value = 'some value'; will not work in all browsers. Use instead:

theTextarea.appendChild(document.createTextNode('blah'));

That actually makes some sense. If you think about it, that's what the value of a textarea element is, a text node. It gets rendered literally, like if you have:


<textarea cols=70 rows=2>
<span>Test</span>
</textarea>

The span is nothing other than a text node and will not be rendered as an element.

However, in general, it is also the value of the textarea. So, as I was saying before, only if it causes a problem in your code should you worry about this.

BTW, I'd love to know which browsers you had a problem with using the value property:


textarea.value = 'some_value';

and whether or not they are exclusively the same as the ones that won't work with:


textarea.setAttribute('value', 'some_value', 0);