You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Archie Cowan <ar...@gmail.com> on 2006/02/08 22:50:51 UTC
CForms button clicks verses enter in IE
We have a set of cocoon forms that are split into multiple pages by changing
the widget state on a group of widgets that make up the different pages when
buttons are pushed on the page. These are pretty much the same thing as the
multipage example except it's not using the ajax feature at this time.
Our testers have found an issue that seems to be only in IE where if they
push enter to submit a form rather than clicking the "next page" button, the
"next page" button logic is not executed. The showForm function in our flow
exits which leaves us with incomplete data that we expect to receive from
the form. In a non-cforms application we've solved this by setting
javascript a listener to capture the enter event and clicking the default
button for the user so the correct values of the form are sent.
Has anyone else run into this issue? We're going to try our old solution but
if there is a way that fits better with the CForms scripting we would rather
use that.
Environment:
JBoss 4.0.3
Cocoon 2.18
Thanks for any advice,
Archie
Re: CForms button clicks verses enter in IE
Posted by Archie Cowan <ar...@gmail.com>.
On 2/9/06, Antonio Fiol Bonnín <an...@gmail.com> wrote:
>
>
>
> On the server, where you check whether the "next page" submit widget
> has been used (javaflow, flowscript,...), if "no widget" has been
> used, you can assume it's "next page", possibly unless you are on the
> last page, where it means "Finish".
I was able to get what I needed by doing this in a loop:
form.showForm("mypipeline");
if(form.getWidget().getSubmitWidget() != null) {
// submit the form as usual
} else {
// figure out what button the user wanted or show the form again
}
Thanks for the pointer.
For any developers listening, it'd be nice to have some default behavior in
the form class that figures out if the real submit button was used. Maybe a
toggleable exception so our flows can catch it and do something with it or
have the form not be submitted at all unless someone uses a button. Or
perhaps a configured default button in the model. So if a "default" button
was visible and there were no clicks on buttons to submit a form, the
"default" button's on-action could be called.
Just a thought. Thanks again.
Re: CForms button clicks verses enter in IE
Posted by Antonio Fiol Bonnín <an...@gmail.com>.
2006/2/8, Archie Cowan <ar...@gmail.com>:
> We have a set of cocoon forms that are split into multiple pages by changing
> the widget state on a group of widgets that make up the different pages when
> buttons are pushed on the page. These are pretty much the same thing as the
> multipage example except it's not using the ajax feature at this time.
>
> Our testers have found an issue that seems to be only in IE where if they
> push enter to submit a form rather than clicking the "next page" button, the
> "next page" button logic is not executed. The showForm function in our flow
> exits which leaves us with incomplete data that we expect to receive from
> the form. In a non-cforms application we've solved this by setting
> javascript a listener to capture the enter event and clicking the default
> button for the user so the correct values of the form are sent.
>
> Has anyone else run into this issue? We're going to try our old solution but
> if there is a way that fits better with the CForms scripting we would rather
> use that.
>
> Environment:
> JBoss 4.0.3
> Cocoon 2.18
>
> Thanks for any advice,
>
> Archie
>
On the server, where you check whether the "next page" submit widget
has been used (javaflow, flowscript,...), if "no widget" has been
used, you can assume it's "next page", possibly unless you are on the
last page, where it means "Finish".
--
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org