Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      796
    • Status Whiteboard:
      Hide

      size_small importance_small

      Show
      size_small importance_small

      Description

      Imagine you have a page with a required UIViewParameter called input. You will
      get a validation error as long as you don't access the view with ?input=abc. Now
      if you do that once, "abc" will be saved as the submittedValue in the state of
      the UIViewParameter for every postback and thus will be available for every
      further postback. If you now access the view again with a GET request
      (non-postback), but without ?input=abc, you will again get a validation error.
      However, if you hit any button or link on the view to generate another postback
      to the view, the validation error will be gone, because UIViewParameter takes
      the value from before ("abc") out of the model (managed-bean) and sets it in the
      state. Thus you haven't provided it via ?input=abc, but you will now have a
      value of "abc" for your UIViewParameter, which seems kinda wrong to me. The
      solution to this one is to get the value from the model to set it as the
      submittedValue in UIViewParameter only if the current request is a postback.
      However I don't know if this really is an error or the expected behaviour. I
      personally just think that it is weird.

      Answer from Martin Marinschek: "I absolutely agree that we should do this only
      on a postback - everything else is really, really weird behaviour."

        Activity

        Jakob Korherr created issue -
        Hide
        Ed Burns added a comment -

        Move to 2.1.

        I agree with this approach.

        Show
        Ed Burns added a comment - Move to 2.1. I agree with this approach.
        Hide
        Ed Burns added a comment -

        triage

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

        rogerk

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

        triage

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

        triage

        Show
        rogerk added a comment - triage
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 796 20401
        Ed Burns made changes -
        Assignee rogerk [ rogerk ]
        Ed Burns made changes -
        Fix Version/s 2.3 [ 16372 ]
        Fix Version/s 2.2 [ 10403 ]
        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.
        Ed Burns made changes -
        Priority Major [ 3 ] Trivial [ 5 ]
        Fix Version/s 2.3 [ 16372 ]
        Ed Burns made changes -
        Priority Trivial [ 5 ] Minor [ 4 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Jakob Korherr
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: