In Relation To

Back to home

RichFaces 4 Overview. Part II – Skinning Mechanism

Posted by    |      

Returning back to this series

After the short vacation I’m planning to spend more time to this series of articles. If you have not seen the previous post – the series started from Ajax Requests Queuing article. And current one (pretty simple to smoothly start after good rest :) ) will be related to our skinning mechanism which was reworked in 4.x. The main redesign reasons:

  • Proprietary XML based xcss format of stylesheets in 3.3.x
  • JSF 2 provides resources API and which we should reuse instead of providing our own one

Overview

Nothing changed from the main concept point of view – just the same good known 3-level scheme:

  • Skin property file which contains limited set of properties which reused in style sheets for different components.
  • Stylesheets for the components which contains predefined classes for the components which are based on skin parameters and additional specific properties. That predefined classes intended to be used by end-developers in order to make bulk changes for all the components which uses them in the view.
  • A class attributes for all the components parts available on components. They allow customizing concrete components in view making them looks differently from the other similar ones.

Note: if you not familiar with that base principles but just starting evaluating RichFaces starting from 4.x – just check reference guide from 3.3.3 Final. It contains them well described.

Usage problems from 3.3.x

The main problem was in xcss stylesheets format which we are used for development. Look to the simple panel stylesheet from RichFaces 3.3.3: 

<?xml version="1.0" encoding="UTF-8"?>
<f:template xmlns:f='http:/jsf.exadel.com/template'
   xmlns:u='http:/jsf.exadel.com/template/util' 
   xmlns="http://www.w3.org/1999/xhtml" >
 	<u:selector name=".rich-panel">
		<u:style name="background-color" skin="generalBackgroundColor" />
		<u:style name="border-color" 	 skin="panelBorderColor" />
	</u:selector>
	<u:selector name=".rich-panel-header">
		<u:style name="background-image" >
    	    <f:resource f:key="org.richfaces.renderkit.html.GradientA"/>
		</u:style>
		…
	</u:selector>
… more selectors
	<f:verbatim>
		<![CDATA[
		.rich-panel{
			border-width: 1px;
			border-style: solid;
			padding : 1px;
		}
… more classes   
	</f:verbatim>
</f:template>

At first – it’s not the CSS we all are known. And that’s the main problem for the developer and designer which should learn new formats in order to work successfully with the xcss files during components development. The second problem – IDE knows nothing about that format – so the file can’t be conveniently edited there.

The new approach to stylesheets definitions

But we can’t change our stylesheets just to CSS ones. And the reasons are pretty simple. At first - we need them to be based on our skin properties and so allow EL expressions inside. You could say that JSF already allows EL in css.. And that’s true. But it’s configurable there and could be turned off. But we can’t allow it as skinning is core RichFaces feature and components relies on that functionality much. So we implemented new ECSS(extended css stylesheets) proposal and now the stylesheets looks like standard css files but with EL expressions inside.

Let’s see the same panel stylesheet but from 4.0.0.M1: 

.rf-panel{
	background-color:'#{richSkin.generalBackgroundColor}';
	color:'#{richSkin.panelBorderColor}';
	border-width:1px;
	border-style:solid;
	padding:1px;
}
   
.rf-panel-header{
background-image:"url(#{resource['org.richfaces.renderkit.html.GradientA']})";
}
… other classes

Now it looks much better and could be easily read by the persons which working on skins implementation. Also opened in CSS editor it should be displayed fine and allow to use extended editor options as for standard CSS ones.

How to load the custom ecss stylesheets

There is nothing new for those who read the numerous blog entries about new JSF 2 features. You still need the same resources inclusion with h:outputStyleSheet from the pages: 

<h:outputStylesheet name="panel.ecss"/>

Or to use ResourceDependency annotation for your class: 

@ResourceDependency(name = "panel.ecss")
Supposed that resources plased in the root of resources folder.

Other changes and what on our way:

In RichFaces 3.3.2 and 3.3.3 releases we made good work on eliminating unnecessary predefined style classes which caused HTML code to be grown up to 50% for complex components like tables and trees. That’s good result for sure. But in 4.x we added one more minor improvement. We defined CSS classes naming convention which intended to reduce them more and so produce less HTML code in the result.

The next big step for us is to defer java2d buffered image usage which causes RichFaces to be incompatible with Google Applications Engine. That could be tracked in our Jira and the questions always welcome at our Forum!

What's next on my way there

This series will be continued in order to describe the main components which already ported to 4.x codebase. I expect to have about one article in a week and will do my best to help you start with RichFaces 4 in your development!

Besides - I was offered to review JSF 2.0 Cookbook from Packt Publishing and accepted it with pleasure. So will post my review soon.

Back to top