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

[Pavol Pitoňák]

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