[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Kienenberger updated TOMAHAWK-914: --------------------------------------- Resolution: Fixed Fix Version/s: 1.1.6-SNAPSHOT Status: Resolved (was: Patch Available) Fixed. Thanks, Jeff. > t:dataTable style attributes don't work with Facelets > ----------------------------------------------------- > > Key: TOMAHAWK-914 > URL: https://issues.apache.org/jira/browse/TOMAHAWK-914 > Project: MyFaces Tomahawk > Issue Type: Bug > Components: Extended Datatable > Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT, 1.1.6-SNAPSHOT > Environment: MyFaces Core 1.1.5, Facelets 1.1.11 > Reporter: Jeff Bischoff > Fix For: 1.1.6-SNAPSHOT > > Attachments: all-in-one.patch, HtmlDataTable.java.diff, > JSFAttr.java.diff > > > Problem: style and styleClass attributes on t:dataTable do not work in > Facelets due to use of fully-qualified names in the map. > Fix: Patch attached to resolve this by changing the names as stored in the > map. Includes code to accept hacks based on the old behaviour, but warns that > it is now deprecated. > Bonus: Also includes fix for problem in Facelets where the EL can not return > a null style. This is due to changes in the EL spec, and prevents the former > (very useful) style rollover behaviour. Fix works by converting any empty > String returned by the EL in these Style attributes into null. (Reverse > Coercion) > Background: > After converting my application from JSP to Facelets, I set out to make my > "rowStyleClass" attribute on t:dataTable work like it used to. > First, I had to get the attribute working in Facelets. With considerable > discussion on the user list (see [1] and [2]) and a lot of help from Mike, I > think we've identified some pretty simple code changes to enable this and > other similar attributes. I plan to introduce a patch for this, probably > tomorrow. > What happened next was that during testing of this change, I could confirm > that the attribute did indeed now work, but I was baffled by unexpected > behaviour. My EL expression which had previously returned null in certain > situations was now returning the empty String. I went to Facelets list for > some clarification on this (see [3]) and it turned out to be a requirement of > the new EL spec to coerce the nulls into empty string. > Getting an empty String instead of null for this ValueBinding lookup creates > a problem because the extended dataTable treats a null value differently and > goes looking at the more standard style attributes like rowClasses. With an > empty string returned, it assumes it needs to look no further. As a user, > there is no way for me to specify that under certain conditions, it should > fallback to the other style attributes, e.g. rowClasses. > The best fix we have collectively come up with so far is to coerce the empty > string back into a null in the dataTable, so that the renderer does the right > thing. I don't see too much downside to this approach, as an empty style > string has no relevance in CSS. However, I feel a proposed change like this > requires extra discussion before making a decision on it. It's another one of > those situation where we have to decide how we want to handle unexpected > results due to changes in the newer specs. > [1] https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=6875 > [2] > http://www.nabble.com/Re%3A-Facelets-support-for-a-Tomahawk-dataTable-trick--tf3236491.html > [3] https://facelets.dev.java.net/servlets/ReadMsg?list=users&msgNo=6941 > Regards, > Jeff Bischoff > Kenneth L Kurz & Associates, Inc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.