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

[Lukas Fryc]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/richfaces-dev
>
>
>
> _______________________________________________
> richfaces-dev mailing list
> richfaces-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/richfaces-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/richfaces-dev/attachments/20131029/88d11da0/attachment.html