You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Jeff Bischoff (JIRA)" <de...@myfaces.apache.org> on 2007/02/28 21:53:50 UTC
[jira] Created: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
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
Environment: MyFaces Core 1.1.5, Facelets 1.1.11
Reporter: Jeff Bischoff
Attachments: 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.
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes
don't work with Facelets
Posted by Jeff Bischoff <jb...@klkurz.com>.
Done. :D
Mike Kienenberger wrote:
> Jeff,
>
> I think a single diff file is easier, so go ahead and update the
> documentation.
>
>
> On 3/2/07, Jeff Bischoff (JIRA) <de...@myfaces.apache.org> wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427
>> ]
>>
>> Jeff Bischoff commented on TOMAHAWK-914:
>> ----------------------------------------
>>
>> I have attached "all-in-one.patch", which implements both of the
>> previous changes but in one single diff file. This is more similar to
>> patches that I have seen applied from other JIRA issues. Hopefully it
>> will be easier to apply.
>>
>> If this is the correct procedure to submit one single diff file with
>> all changes, I should update the wiki [4] with that information.
>>
>> [4] http://wiki.apache.org/myfaces/Contributing_Patches
>>
>> Regards,
>>
>> Jeff Bischoff
>
>
>
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
Jeff,
I think a single diff file is easier, so go ahead and update the documentation.
On 3/2/07, Jeff Bischoff (JIRA) <de...@myfaces.apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ]
>
> Jeff Bischoff commented on TOMAHAWK-914:
> ----------------------------------------
>
> I have attached "all-in-one.patch", which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply.
>
> If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information.
>
> [4] http://wiki.apache.org/myfaces/Contributing_Patches
>
> Regards,
>
> Jeff Bischoff
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes
don't work with Facelets
Posted by Jeff Bischoff <jb...@klkurz.com>.
Mike Kienenberger wrote:
> Unfortunately, I haven't. I'm likely to be pulling down the latest
> MyFaces code in the next week or two and implementing a few things.
> If no one else has gotten to it by then, I'll try to do it at that
> point.
>
Great, thanks.
> On the bright side, your issue has helped me dodge a number of
> potential issues by reminding me that I needed to use some
> fully-qualified attribute names :-)
>
> org.apache.myfaces.dataTable.ROW_STYLECLASS=...
> org.apache.myfaces.dataTable.ROW_ID=...
>
Haha, at least it has done something. ;)
Good, then you will be able to also test if the old workaround still
works after the patch. It should of course also generate the log message
about deprecation of that workaround...
> On 3/14/07, Jeff Bischoff (JIRA) <de...@myfaces.apache.org> wrote:
>> https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480834
>>
>>
>> Has anyone gotten a chance to give this patch a whirl?
>
>
>
Re: [jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't work with Facelets
Posted by Mike Kienenberger <mk...@gmail.com>.
Unfortunately, I haven't. I'm likely to be pulling down the latest
MyFaces code in the next week or two and implementing a few things.
If no one else has gotten to it by then, I'll try to do it at that
point.
On the bright side, your issue has helped me dodge a number of
potential issues by reminding me that I needed to use some
fully-qualified attribute names :-)
org.apache.myfaces.dataTable.ROW_STYLECLASS=...
org.apache.myfaces.dataTable.ROW_ID=...
On 3/14/07, Jeff Bischoff (JIRA) <de...@myfaces.apache.org> wrote:
> https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480834
>
> Has anyone gotten a chance to give this patch a whirl?
[jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
Posted by "Jeff Bischoff (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477427 ]
Jeff Bischoff commented on TOMAHAWK-914:
----------------------------------------
I have attached "all-in-one.patch", which implements both of the previous changes but in one single diff file. This is more similar to patches that I have seen applied from other JIRA issues. Hopefully it will be easier to apply.
If this is the correct procedure to submit one single diff file with all changes, I should update the wiki [4] with that information.
[4] http://wiki.apache.org/myfaces/Contributing_Patches
Regards,
Jeff Bischoff
P.S. Any chance we can also merge this fix into the Tomahawk 1.1.5 release branch? :)
> 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
> 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.
[jira] Updated: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
Posted by "Mike Kienenberger (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
Posted by "Jeff Bischoff (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Commented: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
Posted by "Elena Vilenskaja (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513848 ]
Elena Vilenskaja commented on TOMAHAWK-914:
-------------------------------------------
Hallo!
Still I didn't understand well, how to fix the problem.
Can I download the fixed tomahawk.jar from anywhere or do i have to compile the sources with the patches on my own?
Please, give my answer to the question!
Thanks!
Elena
> 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.7-SNAPSHOT
> Environment: MyFaces Core 1.1.5, Facelets 1.1.11
> Reporter: Jeff Bischoff
> Fix For: 1.1.7-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.
[jira] Updated: (TOMAHAWK-914) t:dataTable style attributes don't
work with Facelets
Posted by "Jeff Bischoff (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Bischoff updated TOMAHAWK-914:
-----------------------------------
Status: Patch Available (was: Open)
> 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
> Environment: MyFaces Core 1.1.5, Facelets 1.1.11
> Reporter: Jeff Bischoff
> Attachments: 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.