You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/09/21 16:35:52 UTC
[2.1.8-dev] No widget should be named'submit' [was: Problems in CForms
in latest from SVN]
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?
Carsten
Carsten Ziegeler wrote:
> Hi after updating to latest from SVN (2.1.x) I have a strange problem
> with CForms. A simple login form which was working with a version from
> last week does not work anymore and throws the following exception:
>
> org.apache.cocoon.ProcessingException: Calling function login
> at [IllegalArgumentException] -
>
file:/D:/dev/workspace-plugins/portal/webapp/coplets/standard/forms/login-model.xml:20:45
> at resource://org/apache/cocoon/forms/flow/javascript/Form.js:47:-1
>
> Interestingly other forms still work. Does anyone have a clue?
>
> Thanks
> Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems
in CForms in latest from SVN]
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: [Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 27-09-2005 a las 11:24 -0400, Doug Chestnut escribió:
> Hi Thorsten,
> This sounds reasonable, even though I have only a little understanding
> of the issue.
:)
Cheers Doug, for your feedback.
salu2
> --Doug
>
> Thorsten Scherler wrote:
> > Hello all,
> >
> > please I would like your opinion on this.
> >
> > IMO we should change all "submit" buttons with "lenya-submit" that would
> > make sure that we are not running in the
> > "property-that-overrides-the-function problem".
> >
> > That means we have to change *all* forms to id="lenya-submit" and
> > triggering code (e.g. usecase-fw
> > http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/usecases/usecases.js?r1=290981&r2=290982&rev=290982&view=diff&diff_format=h)
> >
> > I'm going to implement this unless someone spots a fatal flaw in my plan
> > (lazy consensus is in operation).
> >
> > salu2
> >
> > El vie, 23-09-2005 a las 11:29 +0200, Thorsten Scherler escribió:
> >
> >>El jue, 22-09-2005 a las 22:22 +0200, Sylvain Wallez escribió:
> >>
> >>>Thorsten Scherler wrote:
> >>>
> >>>
> >>>>Yeah, that sounds as well fine. That means I need to add something like:
> >>>><ft:form-template id="something"/>.
> >>>>
> >>>>
> >>>
> >>>Yep. And honestly I strongly recommend not using html form inputs named
> >>>"submit" (be it cforms or not), because sooner or later you will hit the
> >>>property-that-overrides-the-function problem.
> >>>
> >>>Sylvain
> >>
> >>Cheers Sylvain.
> >>
> >>I replied to lenya-dev that we can discuss that over here, because all
> >>our forms right now need to have submit. I agree with Sylvain and thx
> >>for the headsup.
> >>
> >>WDOT?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Prefixing cform ids
Posted by Doug Chestnut <dh...@virginia.edu>.
Hi Thorsten,
This sounds reasonable, even though I have only a little understanding
of the issue.
--Doug
Thorsten Scherler wrote:
> Hello all,
>
> please I would like your opinion on this.
>
> IMO we should change all "submit" buttons with "lenya-submit" that would
> make sure that we are not running in the
> "property-that-overrides-the-function problem".
>
> That means we have to change *all* forms to id="lenya-submit" and
> triggering code (e.g. usecase-fw
> http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/usecases/usecases.js?r1=290981&r2=290982&rev=290982&view=diff&diff_format=h)
>
> I'm going to implement this unless someone spots a fatal flaw in my plan
> (lazy consensus is in operation).
>
> salu2
>
> El vie, 23-09-2005 a las 11:29 +0200, Thorsten Scherler escribió:
>
>>El jue, 22-09-2005 a las 22:22 +0200, Sylvain Wallez escribió:
>>
>>>Thorsten Scherler wrote:
>>>
>>>
>>>>Yeah, that sounds as well fine. That means I need to add something like:
>>>><ft:form-template id="something"/>.
>>>>
>>>>
>>>
>>>Yep. And honestly I strongly recommend not using html form inputs named
>>>"submit" (be it cforms or not), because sooner or later you will hit the
>>>property-that-overrides-the-function problem.
>>>
>>>Sylvain
>>
>>Cheers Sylvain.
>>
>>I replied to lenya-dev that we can discuss that over here, because all
>>our forms right now need to have submit. I agree with Sylvain and thx
>>for the headsup.
>>
>>WDOT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
Hello all,
please I would like your opinion on this.
IMO we should change all "submit" buttons with "lenya-submit" that would
make sure that we are not running in the
"property-that-overrides-the-function problem".
That means we have to change *all* forms to id="lenya-submit" and
triggering code (e.g. usecase-fw
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/usecases/usecases.js?r1=290981&r2=290982&rev=290982&view=diff&diff_format=h)
I'm going to implement this unless someone spots a fatal flaw in my plan
(lazy consensus is in operation).
salu2
El vie, 23-09-2005 a las 11:29 +0200, Thorsten Scherler escribió:
> El jue, 22-09-2005 a las 22:22 +0200, Sylvain Wallez escribió:
> > Thorsten Scherler wrote:
> >
> > >Yeah, that sounds as well fine. That means I need to add something like:
> > ><ft:form-template id="something"/>.
> > >
> > >
> >
> > Yep. And honestly I strongly recommend not using html form inputs named
> > "submit" (be it cforms or not), because sooner or later you will hit the
> > property-that-overrides-the-function problem.
> >
> > Sylvain
>
> Cheers Sylvain.
>
> I replied to lenya-dev that we can discuss that over here, because all
> our forms right now need to have submit. I agree with Sylvain and thx
> for the headsup.
>
> WDOT?
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 22-09-2005 a las 22:22 +0200, Sylvain Wallez escribió:
> Thorsten Scherler wrote:
>
> >Yeah, that sounds as well fine. That means I need to add something like:
> ><ft:form-template id="something"/>.
> >
> >
>
> Yep. And honestly I strongly recommend not using html form inputs named
> "submit" (be it cforms or not), because sooner or later you will hit the
> property-that-overrides-the-function problem.
>
> Sylvain
Cheers Sylvain.
I replied to lenya-dev that we can discuss that over here, because all
our forms right now need to have submit. I agree with Sylvain and thx
for the headsup.
WDOT?
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 22-09-2005 a las 22:22 +0200, Sylvain Wallez escribió:
> Thorsten Scherler wrote:
>
> >Yeah, that sounds as well fine. That means I need to add something like:
> ><ft:form-template id="something"/>.
> >
> >
>
> Yep. And honestly I strongly recommend not using html form inputs named
> "submit" (be it cforms or not), because sooner or later you will hit the
> property-that-overrides-the-function problem.
>
> Sylvain
Cheers Sylvain.
I replied to lenya-dev that we can discuss that over here, because all
our forms right now need to have submit. I agree with Sylvain and thx
for the headsup.
WDOT?
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Prefixing cform ids
Posted by Sylvain Wallez <sy...@apache.org>.
Thorsten Scherler wrote:
>Yeah, that sounds as well fine. That means I need to add something like:
><ft:form-template id="something"/>.
>
>
Yep. And honestly I strongly recommend not using html form inputs named
"submit" (be it cforms or not), because sooner or later you will hit the
property-that-overrides-the-function problem.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: [Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 22-09-2005 a las 21:09 +0200, Sylvain Wallez escribió:
> Thorsten Scherler wrote:
>
> >El mié, 21-09-2005 a las 19:13 +0100, Upayavira escribió:
> >
> >
> >
> >>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?
> >>
> >>
> >
> >+1
> >
> >In lenya we have the usecase-fw where we trigger the submit parameter.
> >
> >
>
> Can you explain "trigger the submit parameter"?
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/usecases/usecases.js?r1=290981&r2=290982&rev=290982&view=diff&diff_format=h
> >Since that is not possible anymore I needed to extend it to allow as
> >well the ok parameter. IMO would be nicer to use cf-submit.
> >
> >
>
> Hmm... I personally prefer Reinhard's proposal to set an @id on the
> form. I updated the check for "submit" so that it is allowed when the
> form does have an id.
>
> Sylvain
>
Yeah, that sounds as well fine. That means I need to add something like:
<ft:form-template id="something"/>.
Cheers again.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [Proposal] Prefixing cform ids
Posted by Sylvain Wallez <sy...@apache.org>.
Thorsten Scherler wrote:
>El mié, 21-09-2005 a las 19:13 +0100, Upayavira escribió:
>
>
>
>>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?
>>
>>
>
>+1
>
>In lenya we have the usecase-fw where we trigger the submit parameter.
>
>
Can you explain "trigger the submit parameter"?
>Since that is not possible anymore I needed to extend it to allow as
>well the ok parameter. IMO would be nicer to use cf-submit.
>
>
Hmm... I personally prefer Reinhard's proposal to set an @id on the
form. I updated the check for "submit" so that it is allowed when the
form does have an id.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
[Proposal] Prefixing cform ids
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 21-09-2005 a las 19:13 +0100, Upayavira escribió:
> 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?
+1
In lenya we have the usecase-fw where we trigger the submit parameter.
Since that is not possible anymore I needed to extend it to allow as
well the ok parameter. IMO would be nicer to use cf-submit.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems
in CForms in latest from SVN]
Posted by Upayavira <uv...@odoko.co.uk>.
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: Problems
in CForms in latest from SVN]
Posted by Reinhard Poetz <re...@apache.org>.
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
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems
in CForms in latest from SVN]
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>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?
>>
>>
>>
>Ok, I pulled my hair out because yesterday my form worked and today not
>:) - Now, I think the real problem is that the error was nowhere to be
>seen, so I had to debug to find this out. Perhaps this is related to the
>problems with logging exceptions as discussed in the other thread. If
>not, we really should present a meaningful exception.
>IllegalArgumentException didn't help me.
>
>So, let's leave it as it is but provide a better exception.
>
>
What about a deprecation exception: "'submit' is not a valid ID name".
Best Regards,
Antonio Gallardo.
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems
in CForms in latest from SVN]
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> 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?
>
Ok, I pulled my hair out because yesterday my form worked and today not
:) - Now, I think the real problem is that the error was nowhere to be
seen, so I had to debug to find this out. Perhaps this is related to the
problems with logging exceptions as discussed in the other thread. If
not, we really should present a meaningful exception.
IllegalArgumentException didn't help me.
So, let's leave it as it is but provide a better exception.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [2.1.8-dev] No widget should be named'submit' [was: Problems
in CForms in latest from SVN]
Posted by Sylvain Wallez <sy...@apache.org>.
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?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109947942619227&w=2
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director