[richfaces-dev] "Necessity for events that represents evident change of component's value (both, manually or externally)"
5:19 a.m.
I would like to address an issue that arose from a discussion
https://issues.jboss.org/browse/RF-13180 .
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
4 p.m.
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:
I would like to address an issue that arose from a discussion
https://issues.jboss.org/browse/RF-13180 .
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
9:20 a.m.
I agree with Brian and Lukas that RF components should have change event aligned with the
HTML and JSF specs. +1 to introducing new component-specific events.
Regarding Metamer, only few vanilla JSF tags are there. Namely there is every JSF input
component with r:ajax and then there are few components used as comparison while we were
working on RF 4.0.0. In general, it's easy to add a new component to Metamer. What use
case do you have in mind?
----- Original Message -----
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:
I would like to address an issue that arose from a discussion
https://issues.jboss.org/browse/RF-13180 .
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
11:20 a.m.
On Wed 23 Oct 2013 07:20:49 AM PDT, Pavol Pitoňák wrote:
Regarding Metamer, only few vanilla JSF tags are there. Namely there
is every JSF input component with r:ajax and then there are few
components used as comparison while we were working on RF 4.0.0. In
general, it's easy to add a new component to Metamer. What use case do
you have in mind?
The use case I have in mind is to explore the behavior of the onchange
event handler for various HTML/JSF elements, so that we can confirm what
is described in the various specifications. In general, having these
elements available in metamer would help similar such comparisons.
Brian
4:59 a.m.
I agree that all components have some event that semantically fits the
idea of component state changed.
It's just not evident what event it is straight away.
I suggest we investigate what is behavior of standard JSF components and
align with whatever they do. As user pointed out in RF-12360, it doesn't
have to be aligned with either HTML standards or even JSF docs themselves.
~ Lukas
On 10/22/2013 11:00 PM, Brian Leathem wrote:
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ás( Fryc( wrote:
> I would like to address an issue that arose from a discussion
> https://issues.jboss.org/browse/RF-13180 .
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/richfaces-dev
_______________________________________________
richfaces-dev mailing list
richfaces-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-dev
4071
days inactive
4079
days old
4 comments
5 participants
participants (5)
-
Brian Leathem -
Brian Leathem -
Lukas Fryc -
Lukáš Fryč -
Pavol Pitoňák