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

HTML input elements without type attribute should be recognized as text inputs

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Works as designed
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: Facelets/VDL
    • Labels:
      None

      Description

      As the type attribute for input elements is optional in HTML and the default value is "text" (as per HTML 4.01), input elements without type attribute should be handled like the type attribute was set to "text".

      See also https://java.net/jira/browse/JAVASERVERFACES-3075

        Activity

        kithouna created issue -
        Ed Burns made changes -
        Field Original Value New Value
        Assignee Ed Burns [ edburns ]
        Hide
        kithouna added a comment - - edited

        The reference implementation (Mojarra 2.2.5) has the strange behaviour that given

        <input jsf:value="#{loginBean.loginName}" jsf:id="loginName"/>
        

        the output becomes (assuming loginBean.loginName is not yet set, i. e. it’s null)

        <input jsf:id="loginName"/>
        

        so it seems as if the element is recognized as a JSF element (because the jsf:value seems to be interpreted in some way and therefore removed) but for some reason only the jsf:id attribute is not treated correctly.

        Working on a new project, I spent way too much time (again) figuring out why the element was not working correctly. Having omitted the type attribute for several years on non-JSF projects, it’s a real unintuitive requirement to include it so maybe you could make sure to lift it for the next JSF version. Please? Maybe increase the priority? Reasoning: It is a major loss of function and the workaround (setting the attribute) is not exactly easy to find when you’re accustomed to rely on the default.

        Show
        kithouna added a comment - - edited The reference implementation (Mojarra 2.2.5) has the strange behaviour that given <input jsf:value= "#{loginBean.loginName}" jsf:id= "loginName" /> the output becomes (assuming loginBean.loginName is not yet set, i. e. it’s null) <input jsf:id= "loginName" /> so it seems as if the element is recognized as a JSF element (because the jsf:value seems to be interpreted in some way and therefore removed) but for some reason only the jsf:id attribute is not treated correctly. Working on a new project, I spent way too much time ( again ) figuring out why the element was not working correctly. Having omitted the type attribute for several years on non-JSF projects, it’s a real unintuitive requirement to include it so maybe you could make sure to lift it for the next JSF version. Please? Maybe increase the priority? Reasoning: It is a major loss of function and the workaround (setting the attribute) is not exactly easy to find when you’re accustomed to rely on the default.
        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 Minor [ 4 ] Trivial [ 5 ]
        Hide
        Ed Burns added a comment -

        I think you are observing the apparently strange behavior because there is not enough information on your <input> tag to disambiguate what sort of input you want. You need to have a "selector attribute" as shown in the javadoc of the TagDecorator class:

        https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/view/facelets/TagDecorator.html

        Show
        Ed Burns added a comment - I think you are observing the apparently strange behavior because there is not enough information on your <input> tag to disambiguate what sort of input you want. You need to have a "selector attribute" as shown in the javadoc of the TagDecorator class: https://javaserverfaces.java.net/docs/2.2/javadocs/javax/faces/view/facelets/TagDecorator.html
        Ed Burns made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Works as designed [ 7 ]
        Ed Burns made changes -
        Attachment spec-1234.zip [ 53685 ]
        Hide
        kithouna added a comment -

        I know why the seemingly strange behaviour happens. I just made the request to make the input type attribute optional to make it easier for developers who are used to omit it (nobody likes to type unnecessary things, right?). It’s optional in plain HTML and it would make the use of JSF a bit easier for newcomers (maybe coming from PHP).

        there is not enough information on your <input> tag to disambiguate what sort of input you want.

        If I don’t write the type attribute then the information is: "I want a text input". Just like in HTML without JSF. It cannot be that hard to map an input without type attribute to h:inputText.

        Show
        kithouna added a comment - I know why the seemingly strange behaviour happens. I just made the request to make the input type attribute optional to make it easier for developers who are used to omit it (nobody likes to type unnecessary things, right?). It’s optional in plain HTML and it would make the use of JSF a bit easier for newcomers (maybe coming from PHP). there is not enough information on your <input> tag to disambiguate what sort of input you want. If I don’t write the type attribute then the information is: "I want a text input". Just like in HTML without JSF. It cannot be that hard to map an input without type attribute to h:inputText.
        Hide
        Frank Caputo added a comment -

        I think, we should allow this behavior, to ease the life of page authors.

        Show
        Frank Caputo added a comment - I think, we should allow this behavior, to ease the life of page authors.
        Manfred Riem made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            kithouna
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: