cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [2.1.8-dev] No widget should be named'submit' [was: Problems in CForms in latest from SVN]
Date Wed, 21 Sep 2005 18:13:04 GMT
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?


View raw message