Hi,
I'm working on getting Sun's basic-ezcomp demo working, and it makes
extensive use of composite components. Most things are working, but I
noticed two issues, one of which I fixed:
First, CompositeComponentResourceTagHandler.createComponent() was
incorrectly checking for required attributes. Basically, it was only
seeing if the BeanInfo's PropertyDescriptors contained a "required"
attribute and threw an error if so. I fixed this to check for the
"required" attribute AND to see if the tag attribute exists or not,
which makes more sense. I have not yet committed this change because
of the next problem.
The second issue I saw, and much more pressing, is that the population
of the BeanInfo and its PropertyDescriptors is "flat" and does not
take into account that composite component attributes can contain
other attributes. For instance, look at the following example from
basic-ezcomp:
<cc:interface name="double" ...>
<cc:attribute name="controller" required="true">
<cc:attribute name="number1" required="true"/>
<cc:attribute name="number2" required="true"/>
</cc:attribute>
</cc:interface>
In this case, the "controller" attribute is supposed to reference a
bean with "number1" and "number2" properties. However, like I
mentioned, when the list of PropertyDescriptors is populated for the
composite component it is "flat", so when validating the tag it's
expected to contain "controller", "number1", and "number2" attributes.
This is obviously incorrect, as only the "controller" attribute is
truly required from the perspective of the person using the composite
component.
Now, I suppose there are two ways to address this. The first would
involve creating a non-flat BeanInfo that would look something like
this:
BeanInfo(double):
PropertyDescriptor(controller) => BeanInfo:
PropertyDescriptor(number1)
PropertyDescriptor(number2)
This would be quite complicated to do because of the way Facelets tags
are visited (at least, that's what I gather from a cursory glance).
Also, this would introduce complexity in
CompositeComponentResourceTagHandler.createComponent().
The second approach would be to simply ignore the nested <attribute>
tags. I think this is the correct thing to do. After all, the user
of the composite component is only concerned with the top-level
attributes and in this case, if the bean listed for "controller"
doesn't have "number1" or "number2" properties, the composite
component implementation won't work anyway (we'd throw an EL
exception).
Please let me know your thoughts.
Thanks,
Curtiss Howard
