[ http://issues.apache.org/jira/browse/ADFFACES-321?page=comments#action_12458244 ] Adam Winer commented on ADFFACES-321: -------------------------------------
The patch is gonna be waaaay too slow. Regular expressions, etc., iteration, all in a key bottleneck. For one thing, the vast majority of calls to this function involve single styles that are *known* to just be single styles (all of the skinning classes). CoreRenderingContext shouldn't be modified. We should do this in XhtmlRenderer.renderStyleAttributes() and anywhere else where getStyleClass(bean) is called. > styleClass attribute values that include spaces need to be treated as > multiple style classes rather than one huge style class > ----------------------------------------------------------------------------------------------------------------------------- > > Key: ADFFACES-321 > URL: http://issues.apache.org/jira/browse/ADFFACES-321 > Project: MyFaces ADF-Faces > Issue Type: Bug > Components: Skinning > Reporter: Matt Cooper > Priority: Minor > Attachments: trinidad.patch > > > If you specify styleClass="Foo" on a component, its encoded HTML will be > something like class="xyz" (the compressed equivalent). > If you specify styleClass="Foo Bar" on a component, its encoded HTML is > class="Foo Bar" when it should have been something like class="xyz xzz". The > reason why the compressed equivalents are not being encoded properly is that > the list of style class names are actually not being treated as a multiple > class names. Instead, the entire string "xyz xzz" is passed into the > RenderingContext.getStyleClass() method rather than tokenizing the string > into each of the style classes first and then passing them into the > getStyleClass() method. > Although the generated CSS files include both totally compressed and totally > uncompressed style definitions, this is still a problem because CSS > definitions span across multiple DOM elements. > Here's a simpler example, let's say we have a (fictional) component called > "companyLogo" with a style of: > af|companyLogo { > background-image: url('red-apache-leaf.png'); > width: 100px; > height: 30px; > } > This makes it easy for page developers to place the logo on their pages by > simply defining: > <tr:companyLogo/> > One day, one of the page developers is working on a page layout and finds > that the logo needs to be placed in a layout area where the layout has a > background red background color. Since the logo is red and the background is > red, the logo will be very hard to see. > Since the page layout has a style defined for the red background: > .MyPageLayoutRedArea { > background-color: red; > width: 500px; > height: 100px; > } > All the page developer needs to do is add one more definition to his or her > skin to make it all better: > .MyPageLayoutRedArea af|companyLogo { > background-image: url('white-apache-logo.png'); > } > The page source looks something like this: > <tr:panelGroupLayout styleClass="MyPageLayoutRedArea"> > <tr:companyLogo/> > </tr:panelGroupLayout> > This works great because the containment style causes the companyLogo to > render with the alternate background image. > However the "MyPageLayoutRedArea" is very specific to the particular page > layout so it's not very reusable. Any extra styles defined in the > MyPageLayoutRedArea container might not always be desired when switching the > logo to a white graphic so it would be best to separate the CSS into proper > groupings like this: > af|companyLogo { > background-image: url('red-apache-leaf.png'); > width: 100px; > height: 30px; > } > .AFDarkToneContainer af|companyLogo { > background-image: url('white-apache-logo.png'); > } > .MyPageLayoutRedArea { > background-color: red; > width: 500px; > height: 100px; > } > Then the page source would look like this: > <tr:panelGroupLayout styleClass="AFDarkToneContainer MyPageLayoutRedArea"> > <tr:companyLogo/> > </tr:panelGroupLayout> > but because of the styleClass value bug described above, the generated HTML > will yield a CSS hierarchy of "AFDarkToneContainer xzz" which is not in the > generated CSS file instead of "xyz xzz" which is in the generated CSS file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
