Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2_04
    • Fix Version/s: 1.2_05
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      464

      Description

      If I build a SelectItem (to insert for example in a HtmlSelectOneMenu) that has
      in the itemValue a string that has HTML characters, itemValue will always be
      escaped even if the escape parameter is false.

      Taking a quick look at the specification the escape parameter is only to affect
      the itemLabel, and nothing is said about itemValue.

      However, always escaping the itemValue is making it impossible to use unicode
      characters in itemValue (like Portuguese characters in my case), because:

      1) If the original itemValue with unicode characters is used, a validation error
      occurs (Value is not valid)
      2) If I change the itemValue to it's HTML escaped value, JSF will double escape
      itemValue, and a manual hack is necessary to revert the double escaping.

      I'm my option there are 4 solutions (in order of correctness, IMHO):

      1) itemValue should never be escaped
      2) The escape flag should also affect itemValue
      3) JSF should always convert unicode characters to the HTML counterparts, since
      any unicode character will not pass validation anyway...
      4) Change the validator so unicode characters are allowed (breaks HTML spec?)

      Thanks,

      Zé

      1. 464.txt
        2 kB
        rogerk
      2. changebundle.txt
        4 kB
        Ryan Lubke

        Activity

        Hide
        Ryan Lubke added a comment -

        r=rlubke.

        Show
        Ryan Lubke added a comment - r=rlubke.
        Hide
        rogerk added a comment -

        checked in.

        Show
        rogerk added a comment - checked in.
        Hide
        rogerk added a comment -

        reopening to mark as wont fix.

        Show
        rogerk added a comment - reopening to mark as wont fix.
        Hide
        rogerk added a comment -

        reverted changes, so marking as won't fix, indicating that the change should be
        in the specification.

        Show
        rogerk added a comment - reverted changes, so marking as won't fix, indicating that the change should be in the specification.
        Hide
        Manfred Riem added a comment -

        Closing issue out

        Show
        Manfred Riem added a comment - Closing issue out

          People

          • Assignee:
            rogerk
            Reporter:
            josefreire
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: