14 Replies Latest reply: May 18, 2011 9:32 AM by 862305 RSS

    ID attribute in JSF components

    862305
      Hello,

      I have a question about the id attribute on JSF 2 components.
      The document says, that it should be a String. Does that mean
      String constant or could it also be a el-expression resulting to a String.

      Actually I can use el-expression for id, but am not sure because of the documentation.

      Any infos about that would be great!
        • 1. Re: ID attribute in JSF components
          gimbal2
          859302 wrote:
          Actually I can use el-expression for id, but am not sure because of the documentation.
          If it works, why are you not sure? You already proved it to yourself :s

          Yes, the ID can be the result of an EL expression.
          • 2. Re: ID attribute in JSF components
            862305
            I am not sure because of the Documentation. There you can read:

            id = java.lang.String not javax.el.ValueExpression (must evaluate to java.lang.String).

            So if the working part is just a behaviour of the current implementation and will change
            someday, because the documentation of the API says so, it would be a bad idea to use it.

            It is not 100% clear for me, but maybe for you. So thats why I ask. I want to know if the
            documentation is wrong or the behaviour of the current implementation.
            • 3. Re: ID attribute in JSF components
              EJP
              Yes, the ID can be the result of an EL expression.
              That's not what it says in the documentation. I agree with the OP. The current behaviour is unspecified and possibly accidental and should not be relied on.
              • 4. Re: ID attribute in JSF components
                r035198x
                859302 wrote:
                I am not sure because of the Documentation. There you can read:

                id = java.lang.String not javax.el.ValueExpression (must evaluate to java.lang.String).
                All java classes inherit a toString method that make it possible to get their java.lang.String representation so it will be difficult to change the implementation so that your code no longer works.

                >
                So if the working part is just a behaviour of the current implementation and will change
                someday, because the documentation of the API says so, it would be a bad idea to use it.
                Why will it change? If java is changed so that objects no longer have a toString method then that id will be the least of your worries.

                >
                It is not 100% clear for me, but maybe for you. So thats why I ask. I want to know if the
                documentation is wrong or the behaviour of the current implementation.
                Documentation is not wrong.
                The ExpressionFactory will set the expectedType of the expression to java.lang.String when the EL expression is used as part of an id attribute because the id class is java.lang.String.
                • 5. Re: ID attribute in JSF components
                  EJP
                  All java classes inherit a toString method that make it possible to get their java.lang.String representation so it will be difficult to change the implementation so that your code no longer works.
                  It would be trivially easy. toString() has nothing to do with it. All they have to do is remove the part that evaluates the EL expression so that it agrees with the documentation. Having said that it is probably more likely that they would expand the documentation to agree with the implementation so as not to break working code, almost certainly including their own.
                  Why will it change? If java is changed so that objects no longer have a toString method then that id will be the least of your worries.
                  Irrelevant as your reasoning on this point is flawed.
                  Documentation is not wrong.
                  The documentation says the type is java.lang.String and says nothing about evaluating it as an EL expression.
                  The ExpressionFactory will set the expectedType of the expression to java.lang.String when the EL expression is used as part of an id attribute because the id class is java.lang.String.
                  You are presupposing the consequent again here. The entire question revolves around whether the OP can continue to rely on the ExpressionFactory having anything to do with it.
                  • 6. Re: ID attribute in JSF components
                    gimbal2
                    EJP wrote:
                    Yes, the ID can be the result of an EL expression.
                    That's not what it says in the documentation. I agree with the OP. The current behaviour is unspecified and possibly accidental and should not be relied on.
                    True, I can certainly agree with that. I'd take it one step further and question the need for an ID to be dynamic. Smells like bad design.
                    • 7. Re: ID attribute in JSF components
                      r035198x
                      EJP wrote:
                      The documentation says the type is java.lang.String and says nothing about evaluating it as an EL expression.
                      The EL experession is evaluated before the id assignment happens and the type of the EL expression is determined by the JSP ExpressionFactory by querying the type returned by getExpectedType(). The type returned by the EL evaluation is not determined by JSF APIs, it's purely a JSP EL issue and has little to do with JSF.
                      The fact that JSF made the component Id a String guarantees that the an EL expression will always work for the id because the context for evaling id="#{....}" will always guarantee expectedType to be String.
                      • 8. Re: ID attribute in JSF components
                        gimbal2
                        r035198x wrote:
                        EJP wrote:
                        The documentation says the type is java.lang.String and says nothing about evaluating it as an EL expression.
                        The EL experession is evaluated before the id assignment happens and the type of the EL expression is determined by the JSP ExpressionFactory by querying the type returned by getExpectedType(). The type returned by the EL evaluation is not determined by JSF APIs, it's purely a JSP EL issue and has little to do with JSF.
                        The fact that JSF made the component Id a String guarantees that the an EL expression will always work for the id because the context for evaling id="#{....}" will always guarantee expectedType to be String.
                        Still, there are a number of JSF properties that cannot be evaluated using an EL expression, so there IS a tight coupling between JSF and the EL API. When something can be an EL expression this is usually specifically documented.
                        • 9. Re: ID attribute in JSF components
                          r035198x
                          gimbal2 wrote:
                          Still, there are a number of JSF properties that cannot be evaluated using an EL expression, so there IS a tight coupling between JSF and the EL API. When something can be an EL expression this is usually specifically documented.
                          Our mileage differs then. UIComponent has a very general setValueExpression method that takes a name and an expression. The only time when that method will fail is if Expression.isLiteralText() throws an exception or if the spec'd type of the attribute is not convertible to the expectedType that will be set by the ExpressionFactory based on the context of invocation. For the id attribute, as long as it is set as id ="#{....}" the context will always allow the ExpressionFactory to set an expected type that is implicitly convertible to String so I don't see the gap in the documentation here.
                          • 10. Re: ID attribute in JSF components
                            EJP
                            The Facelets Tag documentation distinguishes clearly between      'javax.el.ValueExpression
                            (must evaluate to java.lang.String)' and 'java.lang.String'.
                            • 11. Re: ID attribute in JSF components
                              862305
                              Well, I stick with documentation. This is a specification. That means other iplementations like Apache myFaces
                              will also stick to the documentation not for current mojorra implementation or others.

                              That means, an implementation must not evaluate an el-expression. We ar here talking about evaluationg an
                              el-expression and the documentation says, that id must not evaluate el-expressions. At least thats what i understand.

                              So when i use mojorra and use el-expressions fpr id and change to apache implementation of jsf, i might be
                              not working.

                              Also i would get same result, if mojorra implementation someday does not evaluate el-expressions.

                              So it is very important for me and i guess for JSF to clear this point cause it is important for development.
                              One of the posters above mentioned it, is it possible to set dynamic ids for components or not.

                              I always read that it is not wanted. Ids will be generated. But you can give a component an constant id.
                              Like you can easy read in the documentation.

                              You are interpreting the documentation. But JSF is a specification and should not let room for interpretations.

                              If el-expressions are allowed it should be it should be documented.

                              By the way, I think in apache implementation of JSF, el-expressions for id is not allowed.
                              See here:

                              http://www.mail-archive.com/users@myfaces.apache.org/msg20800.html

                              So this implementation does exactly what documentation is saying so for me, mojorra implementation has here a bug!

                              Edited by: 859302 on 18.05.2011 05:23
                              • 12. Re: ID attribute in JSF components
                                862305
                                Well think about GUI-Testsystems. They identify components by id. or other attributes.
                                When you have a list of input components. it is not possible to identfy your input component
                                client side. Here you would need a dynamic id for the input components. Or how do you identify
                                the input with your GUI-Testsystem??

                                Also subview-component requires the attribute id, also String. This attribute is required, but 2.0.4.
                                allows to not define an id. it will just generate a new id. But again, this is a different behaviour than
                                the documentation says.

                                With this behaviour i can really generate kind of dynamic ids. Again, seems for me to be a bug, or
                                the documentation is wrong.

                                So shall i stick with documentation to design my application or not. Thats the reason why i am asking
                                this id subject.
                                • 13. Re: ID attribute in JSF components
                                  gimbal2
                                  Or how do you identify the input with your GUI-Testsystem??
                                  I don't, I've never had any need to test JSF. I'm pretty confident it works. Most of the debugging work to do in views is layout (in other words, CSS), which you are not going to catch with automated tests. I find it more useful to put the time and effort into getting the Java code (unit) tested, so I don't go further than the backing beans.
                                  • 14. Re: ID attribute in JSF components
                                    862305
                                    Well we are using QTP tool to test GUI-Masks, so we need to have a testable application.
                                    You are not testing JSF, but the xhtml-Mask. Sure Unit test we have also.

                                    But think about performance test with JMeter. Same problem...

                                    Edited by: 859302 on 18.05.2011 07:32