Re: Form Submit On Enter

> 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@...
>
>