[ http://issues.apache.org/jira/browse/ADFFACES-321?page=all ]
Matt Cooper updated ADFFACES-321:
---------------------------------
Attachment: trinidad.patch
Updated
trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
The public String getStyleClass(String styleClass) method used to attempt to
compress the entire raw styleClass but now splits it up into individual class
names and compresses them individually.
> 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
