Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2 Sprint 8
    • Fix Version/s: 1.2
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      147

      Description

      The current paragraph about UIComponent component identifier §3.1.1 is not
      consistent with XML NCName (see http://www.w3.org/TR/REC-xml-names/#NT-NCName ),
      that is the type behind XML 1.0 ID see http://www.w3.org/TR/xml-id/

      We should make the specification comply to this.

      Current spec is inconsistent because it result in ambiguous code generation when
      using ID as suffix for ECMAScript generation. An example of that is using "-" in
      a ID like a form (for instance id="test-blah") and using a linkCommand with a
      param will result RI to generate a method name :

      function clearFormHiddenParams_test-blah(curFormName) {
      var curForm = document.forms[curFormName];
      curForm.elements['test-blah:_idcl'].value = null;
      curForm.elements['additionalParameter'].value = null;
      }

      Where the function name is obviously not compatible with ECMAScript !

      Using '-' or even '.' (not allowed in JSF ID at this time) is quite popular in
      XML context, so I do not see any reason to forbid this in JSF.

      Let's make it simple and say that identifiers are XML:id, so the spec then will
      only have to specify the standard way to transform a XML:id to an ECMAScript
      identifier.

      NCName letter (JSF ID letter) --> ECMAScript letters
      '-' --> "$_"
      '.' --> "$$"
      (this mapping was chosen because $ is not allowed in XML:id and is the
      identified by ECMAScript identifier spec as « The dollar sign is intended for
      use only in mechanically generated code ».

        Activity

        Hide
        Ed Burns added a comment -

        Hello, thanks for your input.

        First, the ECMAScript function generated by the Sun implementation to clear the
        hidden form parameters is not part of the spec. Therefore, the existence of
        invalid chars in the name for that function is an implementation bug.

        The spec could say something such as: "The names of any ECMAScript functions
        generated by the JSF implementation must be valid ECMAScript function names.
        When incorporating a clientId or component id in a generated ECMAScript function
        name, any dash '-' characters, must be converted to understore '_' characters."

        Second, the only difference I can see between NT-NCName and 3.1.1 is that 3.1.1
        does not permit dots '.'. Dashes, however, are allowed in JSF 1.2, and I think
        in 1.1 as well. We could widen the requirements, as you suggest and say that
        component identifiers are XML:id. I'll bring this to the EG.

        Show
        Ed Burns added a comment - Hello, thanks for your input. First, the ECMAScript function generated by the Sun implementation to clear the hidden form parameters is not part of the spec. Therefore, the existence of invalid chars in the name for that function is an implementation bug. The spec could say something such as: "The names of any ECMAScript functions generated by the JSF implementation must be valid ECMAScript function names. When incorporating a clientId or component id in a generated ECMAScript function name, any dash '-' characters, must be converted to understore '_' characters." Second, the only difference I can see between NT-NCName and 3.1.1 is that 3.1.1 does not permit dots '.'. Dashes, however, are allowed in JSF 1.2, and I think in 1.1 as well. We could widen the requirements, as you suggest and say that component identifiers are XML:id. I'll bring this to the EG.
        Hide
        bjb added a comment -

        Hello Ed, Tnx for the quick feedback ...

        #1
        Converting only '-' as '_' could result in "name collision" in the generated
        ECMAScript identifier as '_' is also valid in XML:id scope.

        That is the reason of my "odd" proprosition using '$', as an encoding prefix,
        because $ is not part of XML:id, hence the encoding will be bijective. As a
        result, you can still guess the original XML:id from the ECMAScript identifier
        if you know the transformation pattern used.

        As my understanding so far is that Sun's JSF impl is the RI, any non specified
        element but define in the RI is "the reference". I understand that the clearForm
        is specific to this implementation, but any other implementation using any
        ECMAScript generated code will have to care of those encoding issues as well.
        That is why I am advocating for the spec to clarify ECMASCript code generation
        related issues (name collision and encoding problems).

        #2 Great, I would be nice to simplify this by reusing the W3C recommendation as
        long as ECMAScript identifier grammar is satisfied.

        Show
        bjb added a comment - Hello Ed, Tnx for the quick feedback ... #1 Converting only '-' as '_' could result in "name collision" in the generated ECMAScript identifier as '_' is also valid in XML:id scope. That is the reason of my "odd" proprosition using '$', as an encoding prefix, because $ is not part of XML:id, hence the encoding will be bijective. As a result, you can still guess the original XML:id from the ECMAScript identifier if you know the transformation pattern used. As my understanding so far is that Sun's JSF impl is the RI, any non specified element but define in the RI is "the reference". I understand that the clearForm is specific to this implementation, but any other implementation using any ECMAScript generated code will have to care of those encoding issues as well. That is why I am advocating for the spec to clarify ECMASCript code generation related issues (name collision and encoding problems). #2 Great, I would be nice to simplify this by reusing the W3C recommendation as long as ECMAScript identifier grammar is satisfied.
        Hide
        Ed Burns added a comment -

        Fix checked in.

        Show
        Ed Burns added a comment - Fix checked in.
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

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

        Move all to 1.2

        Show
        Ed Burns added a comment - Move all to 1.2
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Ed Burns
            Reporter:
            bjb
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: