Hi 2009/8/27 Curtiss Howard <[email protected]>
> 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. I believe in facelets is valid assign an attribute to a component that "does not exist" or in other words "not declared on the class". I'm not very sure about do that, since the default behavior for normal components should be preserved for composite components. > > > 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). > +1 to ignore inner attribute definitions. It seems to be declarative only (no effects on any programming). For now the code takes them into account but looking in deep it should not. I'm working right now on finish composite component stuff, but I'm still some pending issues so I'll commit all that code at the end of the week. regards Leonardo Uribe > > Please let me know your thoughts. > > Thanks, > > > Curtiss Howard >
