[jira] Updated: (ADFFACES-321) styleClass attribute values that include spaces need to be treated as multiple style classes rather than one huge style class

["Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org>]

     [ https://issues.apache.org/jira/browse/ADFFACES-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Weßendorf updated ADFFACES-321:
----------------------------------------

        Fix Version/s: 1.0.0-incubating-core
    Affects Version/s: 1.0.0-incubating-core

> styleClass attribute values that include spaces need to be treated as multiple style classes rather than one huge style class
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ADFFACES-321
>                 URL: https://issues.apache.org/jira/browse/ADFFACES-321
>             Project: MyFaces ADF-Faces
>          Issue Type: Bug
>          Components: Skinning
>    Affects Versions: 1.0.0-incubating-core
>            Reporter: Matt Cooper
>         Assigned To: Adam Winer
>            Priority: Minor
>             Fix For: 1.0.0-incubating-core
>
>         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.
-
You can reply to this email to add a comment to the issue online.