Reinhard Poetz wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Ok, now I found out the problem:
No top-level widget should be named 'submit' to avoid problems with
HTML <form> elements, at fd:submit
Why did this change? It broke our application and the error message was
nowhere to be seen. It would be good to see at least a message and in
addition I think we should just create a warning here to keep
compatibility, no?
This has been added to 2.2 some months ago. Basically, the big
problem with inputs named "submit" is that they hide the submit()
function on the Form object in the browser document.
This isn't really a problem until you have some event handlers on an
input, that needs to programmatically call form.submit(). In that
case, the form is not submited and there's an JS error in the browser
such as "object is not a function".
I spent many hours finding such problems, and many CForms users
already encountered it (see for example [1]). Hence this decision to
forbid widgets named "submit".
So what should we do: allow widgets named "submit" knowing that it
will break forms with event handlers, or allow it for the sake of
compatibility, letting users pull their hairs with weird broken forms?
I always give my forms an ID in the definition. This creates request
parameters like [form-id].[widget-id]. Enforcing form IDs or setting a
default ID in the case it is missing should solve the problem too,
shouldn't it?
Yep, that's right. I'll take this into account in the check.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
