Gang - I recently triaged a bug that complained that the "type" attribute of <cc:attribute> was not behaving correctly. The user expected the following attribute specification: <cc:attribute name="foo" type="java.lang.Integer"/> To result in a warning/error when used as follows: <comp:bar foo="MostDefinitelyNotAnInteger"/> This seems like a reasonable expectation. An equivalent test case using, for example, JSP tag files does result in an error. This raises a few questions: 1. Should JSF implementations be making use of composite component metadata (like "type") at runtime to enforce the intentions of the composite component author? Yes, assuming this can be done without sacrificing performance.

2. Should this behavior be specified?

3. Are there other places where we have similar metadata (eg. Facelets taglib.xml files) that we should review as well?

Andy

On 2/3/11 10:49 AM, Kito Mann wrote: > 1. Should JSF implementations be making use of composite component > metadata (like "type") at runtime to enforce the intentions of the composite > component author? > Yes, assuming this can be done without sacrificing performance. > There's the rub. I'd be surprised if we could do that without killing performance (which is already one of JSF's most common complaints), though I'd love to see this feature add/specified. We could only do it if the PROJECT_STAGE is set to development, which I think would be sufficient.

-- Jason Lee Senior Member of Technical Staff at Oracle http://blogs.steeplesoft.com

Hi I checked in deep how attribute for composite components works, and here is what I found. This is the javadoc of cc:attribute type: "... Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object  is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored. ..." MyFaces (2.0.3 and earlier) implemented what javadoc says, but in practice Mojarra (tested 2.0.3 and 2.1.0 snapshot branch) behaves different in this case. For example, if it is written this:  <cc:attribute name="foo" type="java.lang.Integer"/> With the following component definition:  <comp:bar foo="5"/> In MyFaces the String "5" is stored on the map, but in Mojarra an Integer 5 is. It is obvious the right behavior is the one shown by Mojarra, even if the javadoc is to explicit about this fact. Now think about a little bit more complex example:  <cc:attribute name="foo" type="java.lang.Integer" default="5"/> both MyFaces and Mojarra fails in this case, because the default is assumed to be a String "5" and not an Integer 5. It is obvious the author expect "type" attribute enforce the value to the type using EL coercions, like it is done for all other components, right? Maybe the javadoc is not explicit, but it is clear the way to go. Now try to get a value programatically instead use EL expressions.  myCompositeBar.getAttributes.get("foo") the default is just ignored. Why? by the spec, composite component default values are handled by "Composite Component Attribute EL Resolver". This is what JSF 2.0 spec section 5.6.6.2 says about it (getValue description) "... get(): if the result of calling get() on the component attributes map is null, and a default value was declared in the composite component metadata, the value will be a ValueExpression. Evaluate it and return it. Otherwise, simply return the value from the component attributes map. ..." In my opinion, we should do that on UIComponent.getAttributes() map instead on an EL resolver, after all we could use the value stored on BEANINFO_KEY to get the descriptor and handle the default value only if all fails. But here is the big question: It is really necessary to support that case? The common case is lookup attributes map using an EL expression #{cc.attrs.myproperty}. This could be necessary only if we do a composite component with a custom component type and we need to play with properties defined on the component class and the composite component definition, but that's very exotic (but theorically possible). Now it is possible to answer the questions (in my personal opinion, based on the previous reasoning): 1.  Should JSF implementations be making use of composite component metadata (like "type") at runtime to enforce the intentions of the composite component author? Ans: Really this is already done, because ValueExpressions are created and values are coerced taking into account the type, but we don't have any code on the default component attribute map class that enforces it. 2.  Should this behavior be specified? Ans: the javadoc of cc:attribute type is incomplete and definitively needs to be fixed. 3.  Are there other places where we have similar metadata (eg. Facelets taglib.xml files) that we should review as well? Ans: User tag handlers does not have any semantic about how to handle attributes, so there is nothing we can do or other places to review (after all, one of the intentions of composite components is provide a transparent way to create components with the flexibility of custom facelets tag handlers). What do we need to do? Fix the bugs on MyFaces and Mojarra related to this issue. regards, Leonardo Uribe