Watch out for this CFFORM issue

I'm working on converting a site to Model-Glue. During the conversion I was copying over a page that had two forms on it. One made use of CFFORM, the other was really just a button to let you link to another page.

For some reason - whenever I hit the button on the second form, the validation for the CFFORM would fire. That didn't make sense. The validation should only apply to the first form.

Here is a subset of the code. See if you can spot something odd before I reveal what the problem was:

<cfform name="Volunteer" action="http://www.cnn.com" method="post"> <table cellspacing="0" > <tr class="odd"> <td><cfinput name="FirstName" type="text" size="10" tabindex="1" maxlength="24" required="yes" message="Please enter a valid First Name." validate="regular_expression" pattern="^[a-z A-Z-]+$"></td> <td><input name="Action" type="submit" value="Add" tabindex="4"></td> </tr>

</cfform>

<cfoutput> </table>

<form name="Finished" action="http://www.yahoo.com" method="post"> <div class="submit"> <input name="Action" type="submit" value="Yahoo"> </div> </form> </cfoutput>

See it yet? Notice the placement of the closing HTML table tab versus the closing CFFORM tag. When rendered out, this resulted in something like so:

<form ...> <table> </form> </table>

Now while I can't imagine why that would mess with validation, when I fixed the order of the tags the validation worked correctly. Form one did it's thing, and form two simply let me load up a new URL.

Archived Comments

Comment 1 by Shane Zehnder posted on 2/10/2008 at 7:27 PM

I don't know the exact situation behind it, but it would seem it would be just as easy to hook a javascript function to the onClick() event of the button instead of making a new form just to go to Yahoo.

Comment 2 by Jeffrey Price posted on 2/10/2008 at 8:10 PM

It's more than likely an issue with your browser's handling of malformed HTML than anything to do with CFFORM.

Comment 3 by Raymond Camden posted on 2/10/2008 at 8:26 PM

Shane - The Yahoo thing was just a sample. I had built a demo outside of the MG site for testing purposes.

Jeffrey - good point.

Comment 4 by Ken Sykora posted on 2/10/2008 at 11:02 PM

Bottom line is, you shouldn't write malformed HTML, and should validate your output with the FF plugin Tidy or the w3c validator.

Comment 5 by Diog Moura posted on 2/11/2008 at 2:38 PM

Try to put ID Attribute in both forms....

Comment 6 by MCSFLORIDA posted on 10/31/2014 at 6:45 PM

Ken - You are the only perfect programmer in the world who *never* writes malformed HTML? I feel the way you've said what you've said was sort of haughty there. Ego check?

*EVERYONE* writes malformed HTML. but from a human perspective a person could look at this piece of code and say "well, the close form tag is definitely in the *WRONG* place -- but it still *clearly* closes before the next form begins."

Malformed HTML or not - a browser *should* still see that the first form is closed by the time the opening <FORM> tag presents itself for the second form.

I'd lean more towards Diog Moura's answer - if you had IDentified each form, your issue probably never would have come up.

That being said, definitely best to move that closing <FORM> tag out of the table.

Comment 7 by Raymond Camden posted on 11/1/2014 at 8:26 PM

@MCSFLORIDA: To be fair, the biggest point of his comment is to *check*, which can be easily automated now and should be part of your dev process.