myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Bischoff (JIRA)" <>
Subject [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Date Wed, 14 Mar 2007 16:52:09 GMT


Jeff Bischoff commented on TOMAHAWK-914:

Has anyone gotten a chance to give this patch a whirl?


> t:dataTable style attributes don't work with Facelets
> -----------------------------------------------------
>                 Key: TOMAHAWK-914
>                 URL:
>             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,,
> 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]
> [2]
> [3] 
> 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.

View raw message