« Return to Thread: Form Submit On Enter
Re: Form Submit On Enter
by Bruno Girin
::
Rate this Message:
Quoting Adam Winer <adam.winer@...>:
> bruno@... wrote:
> > In practice, you could consider that on a form that has only one button,
> this is
> > the default. Otherwise, yes, you would need to specify it.
> >
> > However, "Javascript magic" is not necessarilly the way to go. The reason
> for
> > this is that JS is not accessibility friendly.
>
> This is largely a myth. Javascript can be accessible,
> or it can be inaccessible. Images on a page can be accessible,
> or inaccessible. Plain XHTML, 100% validating, can be
> utterly inaccessible.
Yes I know, Javascript can be made accessible and plain XHTML can be made
inaccessible. My gut feel though is generally to look for a solution that
doesn't involve Javascript because it is something that the user can disable
and that I have no control over. I also know of IT departments that disable JS
on purpose on all browser installations in their companies. Most of the
customers I have worked with also insist on making sure that the site can work
without Javascript for the same reasons.
Of course, any technology can be bad when used improperly, as demonstrated by
the output of some Microsoft tools that manage to build a whole page using HTML
that consists of DIV and SPAN tags laid out and formatted using CSS.
>
> > Also, if you have a form with a
> > lot of text fields (or fields that can have the focus), it means you have
> to
> > assign a JS listener to all of them. This could get messy.
>
> No, you don't. You use event bubbling to capture key presses
> once, on the <form> DOM element.
I didn't know that. Thanks for the tip.
>
> > We solved that problem in a previous job, in a home brewed UI framework, by
> > having the equivalent of the ADF defaultCommand attribute on the form
> rendering
> > tag and storing that value in the HTTPSession. When receiving the form
> back, the
> > framework would attempt to identify the button clicked and if no value was
> > available would get the default value out of HTTPSession.
>
> ... which doesn't work in JSF, because you wouldn't know if something
> else on the page (that isn't a button) triggered a submit.
Well, I can't remember the exact details but we managed to make it work with
plain JSP so I assume that everything that can be done with JSP can be done
with JSF. The gist of it is that when the form is submitted, you know what form
is submitted (if several on the page), there is just no button information. We
took this to mean that the form should be used with the default action.
I'll grant you that doing this you don't know what exact event triggered the
submit (although I can't think of anything other than pressing Enter in the
form) but it seems like a reasonable approach: if no button info, perform the
default action.
Bruno
>
> -- Adam
>
>
> > If you don't want to
> > use HTTPSession, another JS-free solution is to add a hidden field with a
> > well-known ID to your form when rendering it that contains the ID of the
> > default button.
> >
> > I am new to JSF so I don't know what you would override to implement this
> > behaviour but I suspect providing an alternate form rendering object would
> be a
> > good start. I would be nice of JSF/Facelets provided that out of the box
> though
> > :-)
> >
> > Bruno
> >
> > Quoting Adam Winer <adam.winer@...>:
> >
> >> Yep, exactly - the form can't figure out what button was pressed.
> >> There's no magic way for JSF to automatically know what is meant
> >> by the "default button".
> >>
> >> ADF adds a "defaultCommand" property to af:form, so you can have:
> >>
> >>
> >> <af:form defaultCommand="okButton">
> >> ...
> >> <h:commandButton id="okButton" value="OK"/>
> >> ...
> >> </af:form>
> >>
> >> ... and it does the Javascript magic needed to map Enter
> >> to that button.
> >>
> >> -- Adam
> >>
> >>
> >> bruno@... wrote:
> >>> When you submit without clicking a button, the form is sent to the server
> >> by the
> >>> browser but no HTTP parameter is passed to indicate what button was
> clicked
> >>> (because none was) or it is passed with a blank value (I can't recall).
> >>> Therefore, I suppose JSF/Facelets is unable to identify what button was
> >>> activated and what action should be triggered. In practice, it would be
> >> nice if
> >>> JSF/Facelets handled this behaviour properly and assumed that no HTTP
> param
> >> for
> >>> the button means to behave as if the default button had been clicked.
> >>>
> >>> Quoting "Storm, Dan" <dstorm@...>:
> >>>
> >>>> If a text field has focus, the form will submit upon hitting the enter
> (or
> >>>> return) key. This does not seem to work in facelets. Is this a bug in
> >>>> Facelets and/or should we write some JS?
> >>>>
> >>>> dan storm ~ web developer ~ dstorm@... ~ w: 206.266.0292 ~ c:
> >>>> 425.503.9580
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
> bruno@... wrote:
> > In practice, you could consider that on a form that has only one button,
> this is
> > the default. Otherwise, yes, you would need to specify it.
> >
> > However, "Javascript magic" is not necessarilly the way to go. The reason
> for
> > this is that JS is not accessibility friendly.
>
> This is largely a myth. Javascript can be accessible,
> or it can be inaccessible. Images on a page can be accessible,
> or inaccessible. Plain XHTML, 100% validating, can be
> utterly inaccessible.
Yes I know, Javascript can be made accessible and plain XHTML can be made
inaccessible. My gut feel though is generally to look for a solution that
doesn't involve Javascript because it is something that the user can disable
and that I have no control over. I also know of IT departments that disable JS
on purpose on all browser installations in their companies. Most of the
customers I have worked with also insist on making sure that the site can work
without Javascript for the same reasons.
Of course, any technology can be bad when used improperly, as demonstrated by
the output of some Microsoft tools that manage to build a whole page using HTML
that consists of DIV and SPAN tags laid out and formatted using CSS.
>
> > Also, if you have a form with a
> > lot of text fields (or fields that can have the focus), it means you have
> to
> > assign a JS listener to all of them. This could get messy.
>
> No, you don't. You use event bubbling to capture key presses
> once, on the <form> DOM element.
I didn't know that. Thanks for the tip.
>
> > We solved that problem in a previous job, in a home brewed UI framework, by
> > having the equivalent of the ADF defaultCommand attribute on the form
> rendering
> > tag and storing that value in the HTTPSession. When receiving the form
> back, the
> > framework would attempt to identify the button clicked and if no value was
> > available would get the default value out of HTTPSession.
>
> ... which doesn't work in JSF, because you wouldn't know if something
> else on the page (that isn't a button) triggered a submit.
Well, I can't remember the exact details but we managed to make it work with
plain JSP so I assume that everything that can be done with JSP can be done
with JSF. The gist of it is that when the form is submitted, you know what form
is submitted (if several on the page), there is just no button information. We
took this to mean that the form should be used with the default action.
I'll grant you that doing this you don't know what exact event triggered the
submit (although I can't think of anything other than pressing Enter in the
form) but it seems like a reasonable approach: if no button info, perform the
default action.
Bruno
>
> -- Adam
>
>
> > If you don't want to
> > use HTTPSession, another JS-free solution is to add a hidden field with a
> > well-known ID to your form when rendering it that contains the ID of the
> > default button.
> >
> > I am new to JSF so I don't know what you would override to implement this
> > behaviour but I suspect providing an alternate form rendering object would
> be a
> > good start. I would be nice of JSF/Facelets provided that out of the box
> though
> > :-)
> >
> > Bruno
> >
> > Quoting Adam Winer <adam.winer@...>:
> >
> >> Yep, exactly - the form can't figure out what button was pressed.
> >> There's no magic way for JSF to automatically know what is meant
> >> by the "default button".
> >>
> >> ADF adds a "defaultCommand" property to af:form, so you can have:
> >>
> >>
> >> <af:form defaultCommand="okButton">
> >> ...
> >> <h:commandButton id="okButton" value="OK"/>
> >> ...
> >> </af:form>
> >>
> >> ... and it does the Javascript magic needed to map Enter
> >> to that button.
> >>
> >> -- Adam
> >>
> >>
> >> bruno@... wrote:
> >>> When you submit without clicking a button, the form is sent to the server
> >> by the
> >>> browser but no HTTP parameter is passed to indicate what button was
> clicked
> >>> (because none was) or it is passed with a blank value (I can't recall).
> >>> Therefore, I suppose JSF/Facelets is unable to identify what button was
> >>> activated and what action should be triggered. In practice, it would be
> >> nice if
> >>> JSF/Facelets handled this behaviour properly and assumed that no HTTP
> param
> >> for
> >>> the button means to behave as if the default button had been clicked.
> >>>
> >>> Quoting "Storm, Dan" <dstorm@...>:
> >>>
> >>>> If a text field has focus, the form will submit upon hitting the enter
> (or
> >>>> return) key. This does not seem to work in facelets. Is this a bug in
> >>>> Facelets and/or should we write some JS?
> >>>>
> >>>> dan storm ~ web developer ~ dstorm@... ~ w: 206.266.0292 ~ c:
> >>>> 425.503.9580
> >>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@...
> >>> For additional commands, e-mail: users-help@...
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...
« Return to Thread: Form Submit On Enter
| Free embeddable forum powered by Nabble | Forum Help |
