You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bart Molenkamp <b....@bizzdesign.nl> on 2004/11/03 11:33:23 UTC
Bug in forms-lib.js when adding @id to submit buttons?
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
67).
and
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.
When I add the buttons to the form definition, it also works like
expected. So not really a problem, I was just wondering what was going
on (due to the strange exceptions reported by Mozilla).
Bart.
Re: Bug in forms-lib.js when adding @id to submit buttons?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.11.2004 18:49, Sylvain Wallez wrote:
> Don't know, as "action" is an attribute.
Though this part is not translated into English yet, the JS api of the
forms object:
http://en.selfhtml.org/javascript/objekte/forms.htm
The French are somewhat faster:
http://fr.selfhtml.org/javascript/objets/forms.htm
>> It's a problem of HTML, so we should not fix it in CForms IMO.
>> Otherwise it will be a never ending story. It's a 'feature' that
>> should made it into the FAQ.
>
> Ok for the FAQ, but if several people fall into that trap, we may add
> some checks into the HMTL styling part of CForms for some well-known
> cases like "submit".
OK.
Joerg
Re: Bug in forms-lib.js when adding @id to submit buttons?
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 03.11.2004 11:56, Sylvain Wallez wrote:
>
>> 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()"...
>
>
> Indeed a nice one ...
>
>> So the solution is to avoid naming CForms widget "submit"... Maybe we
>> could enforce this at the form definition parsing level?
>
>
> Hmm, I would not do it. On the one hand you can not check the code
> added in the templates as Bart did it. On the other hand form has more
> properties though submit is probably the most used one. What about a
> property 'action'? It would also break the form.
Don't know, as "action" is an attribute.
> It's a problem of HTML, so we should not fix it in CForms IMO.
> Otherwise it will be a never ending story. It's a 'feature' that
> should made it into the FAQ.
Ok for the FAQ, but if several people fall into that trap, we may add
some checks into the HMTL styling part of CForms for some well-known
cases like "submit".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Bug in forms-lib.js when adding @id to submit buttons?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.11.2004 11:56, Sylvain Wallez wrote:
> 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()"...
Indeed a nice one ...
> So the solution is to avoid naming CForms widget "submit"... Maybe we
> could enforce this at the form definition parsing level?
Hmm, I would not do it. On the one hand you can not check the code added
in the templates as Bart did it. On the other hand form has more
properties though submit is probably the most used one. What about a
property 'action'? It would also break the form. It's a problem of HTML,
so we should not fix it in CForms IMO. Otherwise it will be a never
ending story. It's a 'feature' that should made it into the FAQ.
Joerg
Re: Bug in forms-lib.js when adding @id to submit buttons?
Posted by Sylvain Wallez <sy...@apache.org>.
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
>67).
>and
>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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }