+1 When this part was done, I noted this issues on the myfaces tld. All solutions proposed to the observations seem fine for me.
regards Leonardo Uribe On Sat, Jun 21, 2008 at 7:58 AM, simon <[EMAIL PROTECTED]> wrote: > 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 > >
