Form Submit On Enter

[Storm, Dan]

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

[Bruno Girin]

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

[Adam Winer-2]

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

[Bruno Girin]

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

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

[Jacob Hookom]

I can't think of anything Facelets related that would cause that-- usually that behavior only works if there's an input type of submit or image within the form.
	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@...

[Adam Winer-2]

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.

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

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

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

[Bruno Girin]

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

[Martin Marinschek]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Marinschek]

P.S.:

and this is not JSF specific - you have that problem with plain JSP as well.

regards,

Martin

On 3/22/06, Martin Marinschek <martin.marinschek@...> wrote:

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

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jean-Baptiste Bugeaud]

Hello all,

Here is the solution for JSF RI :
http://www.jsftutorials.net/defaultActionTag.html
(take care code need a small improvement to be "facelet-ified" and XHTML-ified)

Plus I would encourage your to post a feature request on the JSF RI
issue tracker for this one ;-)

Regards,
JB

2006/3/22, Martin Marinschek <martin.marinschek@...>:

> P.S.:
>
> and this is not JSF specific - you have that problem with plain JSP as well.
>
> regards,
>
> Martin
>
> On 3/22/06, Martin Marinschek <martin.marinschek@...> wrote:
> > 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
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
> ---------------------------------------------------------------------
> 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@...

[Bjoern Mehner]

If you do not want to use ADF for this: I think j4j is doing the same:

http://www.jsftutorials.net/defaultActionTag.html

greetings, Bjoern Mehner
--------------------------------------------------
Björn Mehner
InterComponentWare AG
Otto-Hahn-Str. 3
D-69190 Walldorf, Germany

Adam Winer <adam.winer@...> wrote on 22.03.2006 00:08:27:

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

[Aleksei Valikov]

Hi.

> If you do not want to use ADF for this: I think j4j is doing the same:
>
> http://www.jsftutorials.net/defaultActionTag.html

The problem with this solution is that the form gets also submitted on
enters pressed within textareas. Currently I've allowed newlines in
textareas on shift+enter, but it's a bit ugly. Could anyone point out a
solution where "enters" presses from textareas are ignored?

I've attached by current solution.

Bye.
/lexi

package de.disy.preludio2.faces.components.defaultaction;

import java.io.IOException;

import javax.faces.component.UIComponent;
import javax.faces.component.UIForm;
import javax.faces.component.UIOutput;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;

public class UIDefaultAction extends UIOutput {

  public void encodeBegin(FacesContext context) throws IOException {
    return;
  }

  public void decode(FacesContext context) {
    return;
  }

  public void encodeEnd(FacesContext context) throws IOException {
    ResponseWriter writer = context.getResponseWriter();
    UIComponent actionComponent = super.getParent();
    String acId = actionComponent.getClientId(context);
    UIForm form = getForm(actionComponent);
    if (form != null) {

      String formId = form.getClientId(context);

      writer.startElement("script", null);
      String functionBody = "{var keycode; var shift;"
          + "if (window.event) {keycode = window.event.keyCode;shift=window.event.shiftKey;}"
          + "else if (event) {keycode = event.which;shift=event.shiftKey;}"
          + "else return true;"
          + "if (!shift && keycode == 13) {"    
          + "document.getElementById('"
          + acId
          + "').onclick(event);return false; } "
          + "else  return true; }";

      String functionCode = "document.forms['"
          + formId
          + "'].onkeypress ="
          + "new Function(\"event\", \""
          + functionBody
          + "\");";
      writer.write(functionCode);

      writer.endElement("script");
    }
  }

  private UIForm getForm(UIComponent component) {
    while (component != null) {
      if (component instanceof UIForm) {
        break;
      }
      component = component.getParent();
    }
    return (UIForm) component;
  }

}

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Adam Winer-2]

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.

Well, this gets into religious arguments, so it's not
especially worth diving into, but my opinion is that such
IT departments are insane.  (And individual users
"can" disable Javascript but very, very rarely do.)

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

You got this to work in JSPs because you didn't have a rich
set of components available, and the only things that triggered
submits were buttons.

In JSF, once you start pulling in any third-party taglib with
interesting components, that heuristic goes totally out the
door.  Of course, every interesting component library out there
also uses Javascript.

-- Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martin Marinschek]

Solution:

function onkeypressListener(event)
{
        var keycode;
        var shift;
        var srcElement;

        if (window.event)
        {
          keycode = window.event.keyCode;
          shift=window.event.shiftKey;
          srcElement=window.event.srcElement;
        }
        else if (event)
        {
          keycode = event.which;
          shift=event.shiftKey;
          srcElement=event.target;
        }
        else return true;

        if (!shift && keycode == 13 && srcElement.tagName !=
'textarea' && srcElement.tagName != 'TEXTAREA') {
          document.getElementById('testSubmit').click();
          return false;
        }
        else  return true;
}

check for the element tag name.

regards,

Martin

On 3/22/06, Aleksei Valikov <valikov@...> wrote:

> Hi.
>
> > If you do not want to use ADF for this: I think j4j is doing the same:
> >
> > http://www.jsftutorials.net/defaultActionTag.html
>
> The problem with this solution is that the form gets also submitted on
> enters pressed within textareas. Currently I've allowed newlines in
> textareas on shift+enter, but it's a bit ugly. Could anyone point out a
> solution where "enters" presses from textareas are ignored?
>
> I've attached by current solution.
>
> Bye.
> /lexi
>
>
> package de.disy.preludio2.faces.components.defaultaction;
>
> import java.io.IOException;
>
> import javax.faces.component.UIComponent;
> import javax.faces.component.UIForm;
> import javax.faces.component.UIOutput;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
>
> public class UIDefaultAction extends UIOutput {
>
>   public void encodeBegin(FacesContext context) throws IOException {
>     return;
>   }
>
>   public void decode(FacesContext context) {
>     return;
>   }
>
>   public void encodeEnd(FacesContext context) throws IOException {
>     ResponseWriter writer = context.getResponseWriter();
>     UIComponent actionComponent = super.getParent();
>     String acId = actionComponent.getClientId(context);
>     UIForm form = getForm(actionComponent);
>     if (form != null) {
>
>       String formId = form.getClientId(context);
>
>       writer.startElement("script", null);
>       String functionBody = "{var keycode; var shift;"
>           + "if (window.event) {keycode = window.event.keyCode;shift=window.event.shiftKey;}"
>           + "else if (event) {keycode = event.which;shift=event.shiftKey;}"
>           + "else return true;"
>           + "if (!shift && keycode == 13) {"
>           + "document.getElementById('"
>           + acId
>           + "').onclick(event);return false; } "
>           + "else  return true; }";
>
>       String functionCode = "document.forms['"
>           + formId
>           + "'].onkeypress ="
>           + "new Function(\"event\", \""
>           + functionBody
>           + "\");";
>       writer.write(functionCode);
>
>       writer.endElement("script");
>     }
>   }
>
>   private UIForm getForm(UIComponent component) {
>     while (component != null) {
>       if (component instanceof UIForm) {
>         break;
>       }
>       component = component.getParent();
>     }
>     return (UIForm) component;
>   }
>
> }
>
>
> ---------------------------------------------------------------------
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...