4 Replies Latest reply on Oct 29, 2013 5:59 AM by Lukáš Fryč

    [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

       

        • 1. Re: [richfaces-dev] "Necessity for events that represents evident change of component's value (both, manually or externally)"
          Brian Leathem Master

          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

          richfaces-dev@lists.jboss.org

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

           

           

          • 2. Re: [richfaces-dev] "Necessity for events that represents evident change of component's value (both, manually or externally)"
            Pavol Pitonak Master

            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 richfaces-dev@lists.jboss.org

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

             

             

            _______________________________________________

            richfaces-dev mailing list

            richfaces-dev@lists.jboss.org

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

             

            _______________________________________________

            richfaces-dev mailing list

            richfaces-dev@lists.jboss.org

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

             

             

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

              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

              richfaces-dev@lists.jboss.org

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

               

               

              • 4. Re: [richfaces-dev] "Necessity for events that represents evident      change of component's value (both, manually or externally)"
                Lukáš Fryč Master

                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

                >> richfaces-dev@lists.jboss.org

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

                >

                 

                _______________________________________________

                richfaces-dev mailing list

                richfaces-dev@lists.jboss.org

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