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

[Brian Leathem]

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 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/20131022/f7b4e34a/attachment.html