[
https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480834
]
Jeff Bischoff commented on TOMAHAWK-914:
----------------------------------------
Has anyone gotten a chance to give this patch a whirl?
JB
> 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
> 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.
