Hi, As those who have been reading the myfaces-builder-plugin thread will have noticed, I've created a tool for comparing TLD files. I've then run this to compare myfaces-core-1.1.6-snapshot with sun 1.1 and myfaces-core-1.1.5.
Please read the last section of this email, if nothing else. It points out some incompatibilities between core 1.1.5 and core-1.1.6-SNAPSHOT that we need to decide how to handle before the 1.1.6 release. First, the comparison between 1.1.6-snapshot and sun's 1.1 release. ==================== core tld: 1.1.6 vs Sun * sun's <taglib> element has no namespace. --> I think myfaces is correct here * sun have no <display-name> element. --> minor, but I think myfaces is correct here * sun has a "tei-class" element. --> this appears to be a "helper" class which validates that tags are used correctly in the JSP page. It appears to be useful but not critical, ie it's ok that we don't have any. * attribute types We output type=String for many attributes. This seems ok to me. The following tags are marked by sun as "JSP" content, but in myfaces as "empty" content: * f:param * f:validateDoubleRange * f:validateLength * f:validateLongRange --> this looks like a Sun bug to me. I don't see why any of these tags should allow nested content. Possibly f:attribute is allowed for validators though? Sun's tld also has this entry. I don't know what it's for: <validator> <validator-class>com.sun.faces.taglib.jsf_core.CoreValidator</validator-class> </validator> So in short, no problems with the 1.1.6-SNAPSHOT tld as far as I can see. We are consistent with sun's version (unlike the core 1.1.5 release). ==================== html tld: 1.1.6 vs Sun * myfaces h:commandLink tag has an "onclick" attribute that is not in Sun's TLD. --> this looks like a Sun bug to me. All the other mouse event handlers are there, so why not onclick? * Sun have this; I'm not sure what it is for. <validator> <validator-class>com.sun.faces.taglib.html_basic.HtmlBasicValidator</validator-class> </validator> ==================== core tld: 1.1.6 vs 1.1.5 == attribute types We now output type=String for many attributes that previously had no type. Example: ActionListenerTag.type or LoadBundleTag.var This seems ok to me. == ValidatorTag Property validatorId was previously required=false. It is now required=true. This looks like a bug in Core 1.1.5, and that the snapshot is correct. ==================== html tld: 1.1.6 vs 1.1.5 == h:commandButton Has a "size" attribute in 1.1.5 that is no longer there in 1.1.6-SNAPSHOT. Sun has no such attribute, so I presume that is a bug in 1.1.5 and 1.1.6-SNAPSHOT is correct. == HtmlDataTableTag The 1.1.5 core release defined the following attributes that are no longer there in 1.1.6-SNAPSHOT: * align * datafld * datasrc * dataformatas Sun has none of these, so I presume that is a bug in 1.1.5. == HtmlInputSecretTag, HtmlInputTextTag Has an "align" attribute in 1.1.5 that is no longer there in 1.1.6-SNAPSHOT. Sun has no such attribute, so I presume that is a bug in 1.1.5 and 1.1.6-SNAPSHOT is correct. == HtmlInputTextArea Has the following fields in 1.1.5 that are no longer there in 1.1.6-SNAPSHOT: * datafld * dataformatas * datasrc == HtmlMessageTag: Had the following in 1.1.5: * dir * lang * onclick/ondblclick/onkeydown/onkeypress/onkeyup/onmouse* == HtmlMessagesTag * dir * lang * onclick/ondblclick/onkeydown/onkeypress/onkeyup/onmouse* etc. So we appear to have shipped a TLD in core-1.1.5 that declares a whole lot of properties that aren't in Sun's impl. In the cases that I have checked, the tag class does actually implement the necessary setter method, and ends up placing the specified value into either the component value-bindings or the component attributes map. So these extra attributes do work. ** Important Question ** What should we do about these? Removing them might break user code, but they don't seem to comply with the JSF spec (even though the TCK doesn't seem to pick this problem up). For JSF1.1, it seems that user code can be fixed fairly easily by just moving these extra attributes to a nested <f:attribute> instead. And f:attribute (AttributeTag) works just like the existing code: creates a ValueBinding or stores into the Attributes map for the component. So although it is a breaking change, it is one that is fairly simple to fix. For JSF1.2, however, I seem to remember that f:attribute evaluates its value immediately. Do I remember right? If so, then user code that puts an EL expression into one of these "custom" attributes can't easily be fixed to work as it did before. I'd personally suggest that we leave 1.1.6-SNAPSHOT as is, ie remove these "custom" attributes. This makes us consistent with Sun. And add a big warning to the release notes about this issue. Regards, Simon
