cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Bug in forms-lib.js when adding @id to submit buttons?
Date Wed, 03 Nov 2004 10:56:56 GMT
Bart Molenkamp wrote:

>Hi all,
>I was wondering if I found a bug in CForms. I have a union widget, with
><fi:styling submit-on-change="true"/>. At the bottom of my form, I have
>a submit button. When the button looks like this:
><input type="submit" value="Continue"/>
>Then the form is submitted when the union has changed (which is the
>correct and expected behaviour). But when I add the id attribute to the
>submit button, it doesn't work anymore:
><input type="submit" id="submit" value="Continue"/>
>The reason to add the id is because I want more submit buttons with
>different behaviour (e.g. a cancel button and a submit button). Looking
>in the JavaScript console of Mozilla, I get the errors:
>Error: form.submit is not a function (http://..../forms-lib.js, line
>Error: uncaught exception: Permission denied to get property
>HTMLDivElement.parentNode (line 44). This is in forms_getForm(), where a
>recursive loop searches for the "FORM" tag.

Hehe, I ran into this one several times :-)

The problem is not in CForms, but in HTML: each form element (input, 
button, etc) is added as a property of the form it belongs to. Problem 
is that these new properties hide those that may already exist with the 
same name on the form.

And a form already has a "submit" property which is a function, which 
means that if you have an <input name="submit">, we can no more 
programmatically submit the form using "form.submit()"...

So the solution is to avoid naming CForms widget "submit"... Maybe we 
could enforce this at the form definition parsing level?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message