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?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
