Re: Form Submit On Enter

> well,
>
> in one of my current projects, we have a situation where the page is
> cluttered with:
>
> onchange="submit();"
>
> I suppose this is what Adam is referring to.
>
> regards,
>
> Martin
>
> On 3/22/06, bruno@... <bruno@...> wrote:
> > 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@...
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>