And as usual, the info for dealing with rowStyleClass is already on http://wiki.apache.org/myfaces/Use_Facelets_with_Tomahawk, courtesy of Andrew Robinson, complete with a facelets tag handler that works around the issues without changing the tomahawk code.
But it'd sure be nice if it were fixed in the tomahawk source since we keep revisiting it. On 2/21/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Yes, the problem is that JSFAttr.ROW_STYLECLASS_ATTR = "org.apache.myfaces.dataTable.ROW_STYLECLASS" instead of "rowStyleClass" Thus, jsp saves "rowStyleClass" tag values under "org.apache.myfaces.dataTable.ROW_STYLECLASS" while facelets stores them under "rowStyleClass". http://issues.apache.org/jira/browse/TOMAHAWK-523 http://issues.apache.org/jira/browse/TOMAHAWK-35 Again, if the tag file were calling the concrete getters and setters, there'd be no problem. But it's storing this value as a generic attribute. Note also that your patch will have to provide backward compatiblity as per my comment at the end of this issue: http://issues.apache.org/jira/browse/TOMAHAWK-47 This does show what the workaround is, though. Use this in your page code: <t:dataTable ... org.apache.myfaces.dataTable.ROW_STYLECLASS="#{tableData.selectedRowIndex == rowIndex ? 'highlightRow' : null}" value=....> It'd probably be good to get this in the facelets wiki for all of the fully-qualified (or oddly-named) attributes listed in org.apache.myfaces.renderkit.JSFAttr. On 2/21/07, Jeff Bischoff <[EMAIL PROTECTED]> wrote: > I have found the difference in behaviour between Facelets and JSP to > stem from different results in code from the following class: > > org.apache.myfaces.component.html.ext.HtmlDataTable > > In the method getRowStyleClass(), the following line is called: > > ValueBinding vb = getValueBinding(JSFAttr.ROW_STYLECLASS_ATTR); > > > In JSP, this results in a valuebinding with the String that I set (e.g. > #{tableData.selectedRowIndex == rowIndex ? 'highlightRow' : null}). > > In JSP, this valuebinding correctly returns either 'highlightRow' or > 'null' as the value. > > In Facelets, this valuebinding is null. > > Okay, why would this valuebinding be null in Facelets? I could have > understood it failing to properly evaluate the valuebinding due to some > missing variable like "rowIndex", but to have the entire expression null? > > Anybody got any ideas? I'm guessing this has something to do with > Facelets having a different EL implementation? > > Regards, > > Jeff Bischoff > Kenneth L Kurz & Associates, Inc. > > Jeff Bischoff wrote: > > I'll resume looking at this next week. > > > > I have some clues from putting debugging output into the source and > > building locally. I need more time to assess it. > > > > So far, I don't see evidence to support your hunch. The tag handler > > really isn't doing anything special, just a simple: > > > > setStringProperty(component, JSFAttr.ROW_STYLECLASS_ATTR, _rowStyleClass); > > > > We'll see, I need to look at it more. I think though, my problem may be > > that "rowIndexVar" doesn't get set in time. > > > > Regards, > > > > Jeff Bischoff > > Kenneth L Kurz & Associates, Inc. > > > > Jeff Bischoff wrote: > >> Thanks for the assessment Mike. Fortunately I did just finish > >> converting the last few pages of my application to facelets, so > >> hopefully I'll have time to give it a shot next week. I'm going to > >> spend the next half hour or so looking into this issue, for starters. > >> > >> This is not a huge thing, but it's really the only thing that "broke" > >> when switching to facelets. So I'd really like to knock it off. > >> > >> Mike Kienenberger wrote: > >> > Jeff, > >> > > >> > This is really straight-forward stuff. Two hours should be more than > >> > sufficient. > >> > I'd guess it'd take about 5 minutes to cut&paste a similar > >> > getter/setter pair, then replace the attribute name with the new > >> > attribute name. > >> > > >> > The less-obvious part is going to be going into the renderer and > >> > changing the references to the generic attribute (map entry) into a > >> > concrete method call. > >> > > >> > The longest part is going to be testing the changes. > >> > > >> > On 2/15/07, Jeff Bischoff <[EMAIL PROTECTED]> wrote: > >> >> (I've moved this thread to the myfaces-users list, due to it being > >> >> identified as a Tomahawk bug) > >> >> > >> >> Heh, Mike do you ever get tired of answering my questions? ;) > >> >> > >> >> I looked through MyFaces JIRA, and the closest issue I found was > >> >> TOMAHAWK-523. The only difference is that they were trying to use EL > >> >> based off the "var" attribute, whereas I am attempting to use the > >> >> "rowIndexVar". However, this might be the same issue. > >> >> > >> >> That issue is marked "patch available", but there are no files > >> attached. > >> >> I see that one of your comments on the thread indicates that the > >> patch > >> >> provided wasn't sufficient... There were also user comments there > >> about > >> >> it affecting non-facelets, or being fixed in the trunk - both > >> statements > >> >> which are definately not true for my issue. > >> >> > >> >> How involved do you think the fix for this would be? Could it be > >> coded > >> >> in a couple of hours? Should I attempt to write a patch to fix this? > >> >> > >> >> [1] http://issues.apache.org/jira/browse/TOMAHAWK-523 > >> >> > >> >> Mike Kienenberger wrote: > >> >> > I think there are already bug reports open on this for Tomahawk, > >> but > >> >> > you should make sure that this is the case, opening one if > >> necessary. > >> >> > > >> >> > My guess it that the jsp tag handler for t:dataTable is not using > >> >> > standard pass-through code to initialize the rowStyleClass > >> attribute > >> >> > on the t:dataTable component. > >> >> > > >> >> > The fix would be to rewrite the component and tag handler so > >> that the > >> >> > tag handler isn't doing anything beyond passing the arguments > >> through > >> >> > unchanged. > >> >> > > >> >> > On 2/15/07, Jeff Bischoff <[EMAIL PROTECTED]> wrote: > >> >> >> Greetings, > >> >> >> > >> >> >> There is a CSS trick with the Tomahawk extended dataTable that > >> allows > >> >> >> the selected row to be highlighted (or some similar things). It > >> works > >> >> >> great in JSP, and has been passed around on the myfaces mailing > >> >> list and > >> >> >> wiki for some time. The trick goes something like this: > >> >> >> > >> >> >> <t:dataTable id="TheDataTable" > >> >> >> ... > >> >> >> rowClasses="oddRow,evenRow" > >> >> >> rowStyleClass="#{dataTableBacking.selectedRowIndex == > >> rowIndex ? > >> >> >> 'highlightRow' : null}" > >> >> >> rowIndexVar="rowIndex" > >> >> >> .../> > >> >> >> > >> >> >> Unfortunately, when I recently converted my application from > >> JSP to > >> >> >> Facelets, this trick no longer works. (Fortunately, this is one > >> of the > >> >> >> only things that stopped working!) I have heard from other > >> users on > >> >> the > >> >> >> myfaces mailing list who also can't get this to work under > >> facelets. > >> >> >> Apparently, the "rowIndex" variable that t:dataTable creates > >> can't be > >> >> >> resolved in the rowStyleClass expression, even though it works for > >> >> >> components who are children of the table. > >> >> >> > >> >> >> Any idea why this would be different under Facelets? I am > >> thinking of > >> >> >> opening a JIRA issue on myfaces project, since this is their > >> custom > >> >> >> component, but wanted to bounce for ideas here first. Any > >> suggested > >> >> >> workarounds? > >> >> >> > >> >> >> Regards, > >> >> >> > >> >> >> Jeff Bischoff > >> >> >> Kenneth L Kurz & Associates, Inc. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> >> > >> >> >> > >> >> > > >> >> > > >> --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> > >> >> > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > > > > > > > > > > > > >
