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?
I was thining about this just a could of days ago. When we generate a
form, why don't we prefix all names with, say cf-. That way it would be
cf-submit, and there wouldn't be any problem at all. WDYT?
Upayavira
- Re: [2.1.8-dev] No widget should be named'submit' [was: ... Upayavira
-
