I was invited to participate in the review of the new JSF 1.2 Components book written by Ian Hlavats. It describes the basics of JSF technology itself and main points of development using particular component libraries. The book looks very interesting for me as it covers all of the popular JSF component libraries present on the market today. Example Facelets Components chapter is already available for free review - so you can check it right now.

I'll post more detailed information after will finish the review.

On February 5th several members of the RichFaces team presented at Minsk, main building of "Belarusian High Technologies Park". It was really cool day full of good discussions and feedback! Here is our overview of the JSF – RichFaces related presentations.

Nick presenting RichFaces 4

We started with a JSF 2 presentation and a practical feature show case. The attendees were happy to hear about all the changes in the specification and about all the good features which have been added. As most of them were familiar with Seam 2 and RichFaces 3 – many of the features which have been added to standard are already known. But it was really good news that those features are now part of the spec. Some good questions came up as well. Like new scopes usage and transactions management in the view scope was discussed. Also JSP deprecation reasons were mentioned. Most popular question was performance, so we also talked a lot about new features like partial state saving which addresses the problems in JSF 2.

The next presentation was on RichFaces 3.3.x. I was happy to know that most of the questions related to RichFaces usage are ones that we are already addressing in 4.x:

• Addend's were very concerned about interoperability with the other JSF frameworks like PrimeFaces

As you may have seen in Jay’s blog we are also concerned about this point, and are planning tasks related to interoperability , including working with other component frameworks.

• Client side performance problems (especially with tables) were mentioned

We have made many optimizations in the latest 3.3.3 version. So many of the questions were solved. Unfortunately some of them require huge redesign which is not acceptable for stabilization branch – so some of the remained problems will be addressed in 4.x.

• More Client side API was requests. The point was that it still easier in some cases to write custom JavaScript controls than use our API because of problems with customization.

This point also addressed in our requirements and planning wiki pages for 4.x version. Many of the components which were done before 3.2 really lack JavaScript API and some customization could require JS coding. But starting from 4.x this will be one of the check-points for every component.

• Also some people asked good questions about our skinning feature and ways to create custom skins.

plug-n-skin usage for creation skins for applications were discussed.

Then Nick made presentation on RichFaces 4. And most of discussions from JSF 2 presentation were touched again but concerning development components with new CDK and applications with future RF 4.x versions.

After the talk questions related to mobile devices development came up. This question did not surprised us – we are already thinking about plans for mobile device support work after 4.0 releases. Our presentations available at:

• JavaServer Faces 2.0

• RichFaces 3.3

• RichFaces 4.x

5th February several members of the RichFaces and JBoss Tools teams will be presenting at the Modern Java Technologies Workshop in Minsk, Belarus.

From the RichFaces team Nick Belaevski and myself will be discussing Java Server Faces 2.0, and then two topics on RichFaces 3.3.X and 4.0.X.

Full list of Topics:

• Java Contexts and Dependency Injection for the Java EE platform (Seam 3 and Weld overviews) by Maksim Kaszynski
• JavaServer(tm) Faces 2.0 by Ilya Shaikovsky and Nick Belaevski
• RichFaces 3.x & JSF 1.2 by Ilya Shaikovsky
• RichFaces 4.x & JSF 2.0 by Nick Belaevski
• Jboss Developer studio overview by Maxim Areshkau
• Visual Page Editor in JBoss Tools by Yahor Radtsevich
• Hibernate Tools in JBDS by Denis Maliarevich

If you are in the area this sounds like a fantastic day of presentations and topics for anyone interested in the latest Java technologies!

Some time ago I published an article at jroller in order to show how the rich:calendar performance can be improved by using single component instance for all the date inputs on the form. Today I want to use the same workaround to solve another popular problem.

Looking through the community forum I see that many people are having issues related to extended/scrollable tables and embedded components with absolute positioning. These components can be cutoff by the tables borders. Unfortunately it's too late for markup redesign for tables components in 3.3.x because only stabilization works planned for the branch.

In this entry I want to highlight that for the rich:calendar component you can use the solution described in original article to make it work when embedded in tables. I'll also add small update for the article code sample in order to make it works with the latest RichFaces 3.3.3.

Lets check this simple table definition:

<rich:extendedDataTable
	value="#{dataBean.simpleList}" var="list"
	width="300px" height="400px"
	rowKeyVar="rowKey">
	<rich:column>
		<f:facet name="header">
			<h:outputText value="row number" />
		</f:facet>
		<h:outputText value="#{rowKey}" />
	</rich:column>
	<rich:column>
		<f:facet name="header">
			<h:outputText value="calendar" />
		</f:facet>
	<rich:calendar />
	</rich:column>
</rich:extendedDataTable>

It will produce the following problematic result:

Now lets move rich:calendar component outside the table and replace it in column with simple input and icon which activates it using api:

<a4j:loadScript src="/scripts/calendarUtils.js"></a4j:loadScript>

<rich:calendar id="calendar" 
onchanged="#{rich:component('calendar')}.customInput.value=event.rich.component.getSelectedDateString();" zindex="1000"/>

<script>
	#{rich:component('calendar')}.customExpand=customExpand;
</script>

<rich:column>
	<f:facet name="header">
		<h:outputText value="calendar" />
	</f:facet>
	<h:inputText value="#{userBean.name}" id="input2" readonly="true"
	onclick="#{rich:component('calendar')}.customExpand(event, #{rich:element('input2')}, #{rich:element('button2')});" />
	<h:graphicImage
	value="resource:///org.richfaces.renderkit.html.iconimages.CalendarIcon"
	onclick="#{rich:component('calendar')}.customExpand(event, #{rich:element('input2')}, #{rich:element('button2')});"
	id="button2" />
</rich:column>

This definitions and calendarUtils.js code is explained in detail in the jroller post. The only thing we need to correct is the script for our calendar initialization. The following lines should be added just after the customExpand function declaration in calendarUtils.js:

function customExpand(e,input,button) {
	 if (!this.isRendered) {
		 this.isRendered = true;
		 this.render();
	 } 

	 ///the rest part fully the same as in original article

This change needed because lazy initialization implemented in calendar in 3.3.3 and without calling render method on the first time calendar call will produce empty calendar to be shown.

And here is expected result for extendedDataTable:

It should became the same used with scrollableDataTable.

This short and I think simple solution is written to answer the main question which rose after this entry and addresses how to highlight updated table cells on the client side.

The main problem here that we are using reRender for the table cells' children elements and not the cells themselves. So we can’t simply define styleClass with some EL-binding on the column to highlight the changes easily. (By the way, the feature of whole cells and even rows updating is already under design for the future 4.x version.)

We will use the data attribute of the push component to serialize a list of changes from the backing bean to the client, and the rich:jQuery component in order to highlight items which correspond to the list.

Full page code (some page parts which are fully similar to the previous post's code are cut to make it shorter):

<ui:composition> 
<style>
.highlight{
	background-color: yellow;
}
</style>
<h:form id="choicesForm">
	<rich:jQuery selector=".votesClass"
		query="each(function(key){
		if (param[key].votesCount > 0) jQuery(this).addClass('highlight'); 
		else jQuery(this).removeClass('highlight'); })"
		name="jqhighlight" />
	<rich:dataTable value="#{choicesBean.choices}" var="choice"
		rowKeyVar="row" ajaxKeys="#{choicesBean.keysSet}" id="choices">
		// All the other columns
		<rich:column id="votes" styleClass="votesClass">
			<f:facet name="header">
				<h:outputText value="Current Votes" />
			</f:facet>
			<h:outputText value="#{choice.votesCount}" id="choiceVotes" />
		</rich:column>
	</rich:dataTable>
		<a4j:push enabled="#{choicesBean.enabled}" interval="3000"
			timeout="3000" eventProducer="#{choicesBean.addListener}" id="push"
			limitToList="true" action="#{choicesBean.processUpdates}"
			reRender="choiceVotes, push, tempResults" data="#{choicesBean.lastVotes}" oncomplete="jqhighlight(null,data)"/>
	</h:form>
</ui:composition>

Let’s review the key changes in this code:

• We added highlight CSS class definition. This class will be applied to the vote's cells which were updated.

• votesClass was added to votes column. It is done in order to use it in jQuery selector. We will search for all the td elements with this class applied.

• data definition added to push component in order to serialize the changes list to the client after update occurs.

• oncomplete added to push in order to call the registered jQuery component which will handle the updates. data parameter contains the serialized changes list. The first parameter could be a DOM element which would later be added to the selector, but as we intended to use the selector by CSS class, we are passing null there.

Let’s review the key addition more closely:

<rich:jQuery selector=".votesClass"
	query="each(function(key){
	if (param[key].votesCount > 0) jQuery(this).addClass('highlight'); 
	else jQuery(this).removeClass('highlight'); })"
	name="jqhighlight" />

• name="jqhighlight" - register the code generated by jQuery component as a JavaScript function with the name specified.

• selector=".votesClass" – creates the selector for the query and the result will be all the elements which have votesClass applied.

• The code defined in query - simply iterate through the elements returned by selector and if the corresponding data element returns a not-null change, this element is given the highlight css class. If there was no change for the element, the highlight class is removed if it exists.

So now the result of push updates will look like this:

Full demo code is available at 3.3.x community branch under richfaces-demo project and can be downloaded from anonymous svn.