javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-437

Immediately process update HtmlInputHidden values during conversion/validation phase

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Lifecycle
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      437
    • Status Whiteboard:
      Hide

      cat2 frame javadoc size_medium importance_small

      Show
      cat2 frame javadoc size_medium importance_small

      Description

      Requested by use balusc
      (https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=765):

      Imagine a request scoped bean with a h:inputHidden field and another UIInput
      field which is to be converted and/or validated. If the h:inputHidden already
      has a value but the conversion and/or validation of the another UIInput field
      fails, then the value of the h:inputHidden will get lost.

      Truly, this is behaviour by specification, but it is not very intuitive. One
      would expect that hidden input values (read: the values which aren't to be
      filled in by the client, but by the server) should retain its value. In real
      world web applications the sole purpose of hidden input elements is to transfer
      values from request to request without any client interaction.

      Thus, hereby my request for an enhancement in the API: make sure that the API
      retains hidden input values regardless of the global outcome of the
      conversion/validation phase. And only if the hidden input value itself is
      already successfully converted and validated.

      In theory this can simply be achieved by adding the following lines at the
      bottom of the if (isValid()) {} block which starts at line 887 of
      javax.faces.component.UIInput in 2.0.0 EDR1:

      if (this instanceof HtmlInputHidden) {
      processUpdates(context);
      }

      If necessary you can also let it implement a certain marker interface, e.g.
      RetainableValueHolder or so (I just say something) so that one can decide to let
      some custom component implement it.

      I am almost sure that this will be greatly appreciated by the web development
      world. It is certainly much more intuitive. And it is much more elegant than the
      'workaround' to bind the h:inputHidden and using the UIInput#getValue() /
      setValue() instead.

        Activity

        Hide
        Ed Burns added a comment -

        Move to unscheduled target milestone

        Show
        Ed Burns added a comment - Move to unscheduled target milestone
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

        Show
        Ed Burns added a comment - Prepare to delete "spec" subcomponent.
        Hide
        kito75 added a comment -

        This is probably more complicated than it seems, because it's quite possible
        that JavaScript code could be updating a hidden field, in which case we would
        want the updates to occur.

        What is the use case for attaching a value to both a hidden field and a field
        with validation?

        Show
        kito75 added a comment - This is probably more complicated than it seems, because it's quite possible that JavaScript code could be updating a hidden field, in which case we would want the updates to occur. What is the use case for attaching a value to both a hidden field and a field with validation?
        Hide
        kito75 added a comment -

        I re-read this, and I now I understand it more clearly. Wouldn't using
        immediate="true" solve this problem?

        Bypassing validation/conversion is generally not a good idea.

        Show
        kito75 added a comment - I re-read this, and I now I understand it more clearly. Wouldn't using immediate="true" solve this problem? Bypassing validation/conversion is generally not a good idea.
        Hide
        kito75 added a comment -

        Changed subcomponent to validation/conversion.

        Show
        kito75 added a comment - Changed subcomponent to validation/conversion.
        Hide
        rogerk added a comment -

        cat2

        Show
        rogerk added a comment - cat2
        Hide
        Ed Burns added a comment -

        javadoc

        Show
        Ed Burns added a comment - javadoc
        Hide
        Ed Burns added a comment -

        These are targeted at 2.1.

        Show
        Ed Burns added a comment - These are targeted at 2.1.
        Hide
        sheetalv added a comment -

        triage

        Show
        sheetalv added a comment - triage
        Hide
        Ed Burns added a comment -

        sheetalv

        Show
        Ed Burns added a comment - sheetalv
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Ed Burns added a comment -

        Bulk assign all of Sheetal's spec issues to me.

        Show
        Ed Burns added a comment - Bulk assign all of Sheetal's spec issues to me.
        Hide
        Ed Burns added a comment -

        Are JAVASERVERFACES_SPEC_PUBLIC-

        {575,437}

        [1] solved by the cancel button work
        we did in JSF 2.2? I think they might be.

        Can you please take a look and check?

        Thanks,

        Ed

        Show
        Ed Burns added a comment - Are JAVASERVERFACES_SPEC_PUBLIC- {575,437} [1] solved by the cancel button work we did in JSF 2.2? I think they might be. Can you please take a look and check? Thanks, Ed
        Hide
        Ed Burns added a comment -

        Cagatay got back to me and confirmed this was not resolved by that work.

        Will target to 2.3.

        Show
        Ed Burns added a comment - Cagatay got back to me and confirmed this was not resolved by that work. Will target to 2.3.
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Manfred Riem added a comment -

        Setting priority to Minor

        Show
        Manfred Riem added a comment - Setting priority to Minor

          People

          • Assignee:
            Unassigned
            Reporter:
            Jason Lee
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: