Thanks for bringing this up Lukas.
It's an issue we've skirted around before and never dealt with
head on, mostly in the context of the pickList component
[1,2,3].
In RF-12360 [1] the user reporting the issue remarked:
"
this is not consistent with standard h:selectOneMenu onchange
behaviour (which fires onchange event immediately)."
This however is inconsistent with the JSF API docs [4] which
state that the onchange attribute is
"
Javascript code executed when this element loses focus and its
value has been modified since gaining focus."
@QE: Do you have metamer configured with vanilla JSF tags? We
should do some investigative work and map out the onchange
attribute behaviour for various HTML elements and JSF tags.
@Lukas I like the idea of leaving keeping the change event
aligned with the HTML and JSF specifications. Introducing a new
event is the right way to go. W.r.t. your point about the
attribute not being supported across all components - I don't
think it's by any means a showstopper.
In fact I would suggest that rather than have a single event
that all components reuse, we rather have each component offer
the change event + some-semantic-event specific to that
component that can be used to trigger earlier notifications.
For example, this would be the "keypress" event in an input
element, or the "select" event in one of the select components,
or the "drag" event for the inputNumberSlider etc.
Brian
[1]
https://issues.jboss.org/browse/RF-12360
[2]
https://issues.jboss.org/browse/RF-12929
[3]
https://issues.jboss.org/browse/RF-11617
On 13-10-21 03:19 AM, Lukáš Fryč wrote:
When
one reacts on changes of value, he can use 'change' event
that have defficiency coming from classic HTML
<input>:
- the
'change' event is fired after 'blur' event when the value
changed between a focus and a subsequent blur event
This
means in component like <r:calendar> or
<r:autocomplete>, a 'change' event is not fired when
input is externally changed by selection of a value from
popup, but only when a value is changed and then input is
blurred.
This
has downside in form of a bad experience:
*
client-side validation is triggered when autocomplete is
blurred, but it could be validated right after selection
from a suggestion box
* so
when one want to react on changes, he need to use
behavior-based (as opposed to semantically-based) events,
such as 'onkeypress', 'onselect'
----
This
defficiency could be solved by introducing new event: e.g.
'valuechanged' which would be defined as:
*
event 'valuechanged' is triggered when component's input is
blurred or the value is changed externally
However,
this solutions has its own drawback coming from a fact, that
this event must be supported by library - so e.g. common JSF
components won't be supported (unless we provide a shim for
them - e.g. event triggering emulation).
~
Lukas
_______________________________________________
richfaces-dev mailing list
richfaces-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev