[richfaces-dev] "Necessity for events that represents evident change of component's value (both, manually or externally)"

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

[bleathem]

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 .

In RF-12360 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 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

https://issues.jboss.org/browse/RF-12360

https://issues.jboss.org/browse/RF-12929

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

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

[ppitonak]

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 .

In RF-12360 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 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

https://issues.jboss.org/browse/RF-12360

https://issues.jboss.org/browse/RF-12929

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 [e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

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

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

[lfryc]

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 .

In RF-12360 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 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

https://issues.jboss.org/browse/RF-12360

https://issues.jboss.org/browse/RF-12929

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  -

---

>>

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

>> [e-mail]

>> https://lists.jboss.org/mailman/listinfo/richfaces-dev

>

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev