Birmingham, UK. 9th August 2010

The 2010 Open Source Awards was launched today by Packt, inviting people to visit www.PacktPub.com and submit nominations for their favorite Open Source project. Now in its fifth year, the Award has been adapted from the established Open Source CMS Award with the wider aim of encouraging, supporting, recognizing and rewarding all Open Source projects.

WordPress won the 2009 Open Source Content Management System (CMS) Award in what was a very close contest with MODx and SilverStripe. While MODx was the first runner up, SilverStripe, a Most Promising CMS Award winner in 2008, made its way to the second runner up position in its first year in the Open Source CMS Award final.

The 2010 Award will feature a prize fund of $24,000 with several new categories introduced. While the Open Source CMS Award category will continue to recognize the best content management system, Packt is introducing categories for the Most Promising Open Source Project, Open Source E-Commerce Applications, Open Source JavaScript Libraries and Open Source Graphics Software. CMSes that won the Overall CMS Award in previous years will continue to compete against one another in the Hall of Fame CMS category. These new categories will ensure that the Open Source Awards is the ultimate platform to recognise excellence within the community while supporting projects both new and old. “We believe that the adaption of the Award and the new categories will provide a new level of accessibility, with the Award recognizing a wider range of Open Source projects; both previous winners while at the same time, encouraging new projects” said Julian Copes, organizer of this year’s Awards.

Packt has opened up nominations for people to submit their favorite Open Source projects for each category at www.PacktPub.com/open-source-awards-home . The top five in each category will go through to the final, which begins in the last week of September. For more information on the categories, please visit Packt’s website www.PacktPub.com/blog/packt’s-2010-open-source-awards-announcement

Contacts

Julian Copes PR Executive, Packt Publishing

julianc@packtpub.com www.PacktPub.com

About Packt

Packt is a modern, unique publishing company with a focus on producing cutting-edge books for communities of developers, administrators, and newbies alike. Packt’s books and publications share the experiences of fellow IT professionals in adapting and customizing today's systems, applications, and frameworks. Their solutions-based books give readers the knowledge and power to customize the software and technologies they’re using to get the job done. For more information, please visit www.PacktPub.com

The series continues and in this entry I will give you an overview of the various panel components which are already ported to RichFaces 4 codebase (M1 release).

Simple Panel component

Actually there is almost nothing to describe as this probably the simplest and most well known layout component in the whole library :).

The following tags...

<rich:panel header="Panel with default Look-n-feel">
    //Content inside 
</rich:panel>

...will be rendered as a skinnable rectangular panel with header on top:

So, let's not to spend much time on that component and go to the more complex ones.

Switchable Panels

This section should be much more interesting and we'll describe the changes in design of the switchable panels.

The first components which was migrated to the 4.0 codebase – Toggle components set. The reason is simple – it's a base one for all the other (TabPanel and Accordion are on our way for M2). The Toggle components set consist of:

• togglePanel – parent component which contains from set of child panels and provides mechanism of switching between them.
• togglePanelItem – child panel component which defines single state representation. In 4.x it's implemented as a child component instead of facet in order to distribute attributes and some component functionality more properly.
• toggleControl – the behavior which performs switching of the panel. The main goal of implementation as a behavior – to provide the way to use any controls for states switching (and maybe to show once more that we are using hottest JSF 2 features :)). That's differs from 3.3.x where it was a component and rendered as HTML link element.

Simple sample of Toggle components usage:

<style>
	.rf-tp-i {
		border: 1px solid #{richSkin.panelBorderColor}
	}
</style>
<h:form>
	<h:commandLink value="Toggle Panel Item 1">
		<rich:toggleControl forPanel="panel1" targetItem="item1" />
	</h:commandLink>
	<h:outputText value=" | " />
	<h:commandLink value="Toggle Panel Item 2">
		<rich:toggleControl forPanel="panel1" targetItem="item2" />
	</h:commandLink>
	<rich:togglePanel id="panel1" activeItem="item1">
		<rich:togglePanelItem name="item1" styleClass="rf-tp-i">
			<p>This toggle panel switches in Ajax mode. 
So only one active
				item loaded to the client.</p>
			<p>For now you are at Panel 1</p>
		</rich:togglePanelItem>
		<rich:togglePanelItem name="item2" styleClass="rf-tp-i">
<p>After the second link click - panel changed active item to the second one according to name specified in the
				togglePanelBehavior</p>
			<p>For now you are at Panel 2</p>
		</rich:togglePanelItem>
	</rich:togglePanel>
</h:form>

And on opening page you will see:

Note: It's also possible to switch between states sequentially without states definition at behavior. In that case the order of the child items will be considered. Could be useful for example for wizard panels creation.

The main ideas of the component has not changed much from 3.3.x – the component provides no predefined layout, and provides only switching between abstract states functionality using different modes. So any kind of switchable panel could be implemented using this component. E.g. example above created simplest tabs. And we could move switching controls to other place and align them as we need easily.

The main change to be considered if you have already used any of the components in 3.3.3 – all the functionality by switching of the states moved to the parent panels components. The controls like toggleControl and future tab or accordionItem control just calls the state change panel methods. Using that way we resolved the following problems:

• All the attributes of the request in non-client mode – configured once at panel level.
• Switching event managed at panel level using ItemChangeListener instead of having bunch of actions and listeners definitions at every control.
• Client API available at panel level. So no more need in JavaScript clicks on controls in order to perform switch.

Learn more about the components at requirements wiki page

Popup Panel

First I need to mention before describing this component - we considered tons of requests on non-modal panel and finally single rich:popupPanel component is there. It has two modes modal and non-modal and renders popup with any content inside.

The usage is simple for those who already played with it in 3.3.x as it's almost not changed:

<h:commandButton value="Call the popup">
	<rich:componentControl target="popup" operation="show" />
</h:commandButton>

<rich:popupPanel id="popup" modal="true"
	resizeable="true" onmaskclick="#{rich:component('popup')}.hide()">
	<f:facet name="header">
		<h:outputText value="Simple popup panel" />
	</f:facet>
	<f:facet name="controls">
		<h:outputLink value="#"
			onclick="#{rich:component('popup')}.hide(); return false;">
				X
		</h:outputLink>
	</f:facet>
	<p>Additionally there you could check how to handle the clicks
	outside the panel.</p>
	<p>In this sample the click outside - closes the panel as well as
	clicking hide control in the header</p>
</rich:popupPanel>

And in the result we will get next popup representation:

In order to use the panel in non modal state you should just use new modal boolean attribute with false value.

It could appear that the component was not changed much from usage point of view – but much work was done in order to optimize markup to make it more lightweight. So we are awaiting for the feedback on that!

Learn more about the popup component at requirements wiki page

What's next:

I guess that the Data Iteration Components overview and articles related to usage of those components will be probably most popular from all those reviews. So what the reason that them still not posted if components were available in A2? It's simple – we already had some good feedback on them and now just making some redesign and changes according to that feedback to make components easier to use and more intelligent. So when the picture on the changes and affect of those changes to usage will become clean – it will be there immediately!

And as I announced in my previous post I'm still reading JSF 2.0 Cookbook from Packt Publishing and also working on the review article continuously.

Any feedback always welcome at our RichFaces Design Space. And we will do our best to help you with any usage problems at RichFaces User Space

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")

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.

About RichFaces 4 Overview

This series of articles is intended to give you a short overview of all the work we've done in extending JSF 2 with advanced features and components.

Core Ajax components

The first part of the RichFaces components migration process contained mostly the a4j library core components, which provide enhanced Ajax functionality. I believe that most of the community knows the base RichFaces Ajax components well and has worked with them for a long time. So basically there is not much to cover in this area. It should be easy to use them in the same manner as it was in RichFaces 3.3.x, but considering the JSF 2 Ajax definitions standards. The first article is intended to provide a short usage overview for them and to describe the RichFaces 4 Ajax requests queuing mechanism, which is designed for easy optimizations of your page/server transactions.

Why do we need them?

So let's start from the beginning. Why we need our Ajax components in a JSF 2 world where Ajax is standardized and provided out of the box in implementations? The answer is simple: JSF is an open standard which provides basic functionality leaving much place for customizations and extensions. They have taken many implementation ideas from RichFaces 3.x and other frameworks and added common base functionality into the JSF 2 standard. However, there are still many use-cases with which implementation requires additional work from a JSF 2 developer. RichFaces intends to provide extensions which will cover most of the features that are absent in JSF but required for real-world web applications.

Simple Ajax usage

Let’s explore the simplest Ajax repeater example in order to start with queuing functionality:

<h:inputText id="myinput" value="#{queueBean.text}">
	<a4j:ajax event="keyup" render="outtext"/>
</h:inputText>  
<h:outputText value="#{queueBean.text}" id="outtext"/>

In this sample, as you can see from snippet, an Ajax request will be generated for every keyup event in the input text and the ''outtext'' will be updated with the new value. If you start typing fast and look at the firebug console, for example, you will see numerous requests rise every time you type a letter.

Good news: JSF 2 provides an Ajax requests queue out of the box! So the frequent requests will not became concurrent, and will be sent one by one and processed in the right order.

But hey, I still need to reduce the requests count. In order to do that I still need to work manually with the timer, and to send my requests using the Ajax API as in the example shown at this article .

Good news again: the RichFaces Ajax requests queue solves the problem, and you can just specify the requests combining rules and pre-sending waiting time declaratively with the page tags.

Let's queue them

The next code snippet defines queue for form or view (depending on where defined):

<a4j:queue requestDelay="1500"/>

requestDelay specifies the time interval in milliseconds before the next request can be sent to server.

So now if we type without delays (or with delays smaller that 1.5 seconds) and then check the requests console, we will see that there is only one request with the latest information that was sent. RichFaces Ajax requests are grouped by using the requestGroupingId option, which is equal to the client id of the component that initiated requests(by default). It’s pretty simple and highly useful for such cases.

A more complex case. How do you group requests from different sources?

Now let's imagine the registration form which contains a few inputs which are validated via Ajax immediately after any changes. Using queue as shown above, a single request appears per input. But what if I don't want to send them at all while the user is entering information and validate the form only when he stops to check the result? It's still simple to do. We just need to add attachQueue with additional parameter passed to the queue:

<h:form>

<a4j:queue requestDelay="1500"/>

<h:inputText id="myinput" value="#{queueBean.text}">
    <a4j:ajax event="keyup" render="fooMessages" execute="@form">
        <a4j:attachQueue requestGroupingId=”registrationForm”/>	
    </a4j:ajax>
</h:inputText>  
<h:inputText id="myinput2" value="#{queueBean.text2}">
    <a4j:ajax event="keyup" render="fooMessages" execute="@form">
        <a4j:attachQueue requestGroupingId="registrationForm"/>	
    </a4j:ajax>
</h:inputText>  
</h:form>

Note: In RichFaces 4 we moved all queue related attributes (requestDelay, requestGroupingId, ignoredupResponse and so on) to a special attachQueue tag in order to keep the components itself cleaner.

The previous code could be rewritten to become much simpler, as we could use wrapping behavior instead of nested:

<h:form>
<a4j:queue requestDelay="1500"/>

<a4j:ajax event="keyup" render="fooId1" execute="@form">
    <a4j:attachQueue requestGroupingId="registrationForm"/>	

    <h:inputText id="myinput" value="#{queueBean.text}"/>
    <h:inputText id="myinput2" value="#{queueBean.text2}"/>
</a4j:ajax
</h:form>

That's it. Now requests from those inputs are similar from the RichFaces queue's point of view. If the user types fast among different inputs, only a single validation request for form will be raised after 1.5 seconds of inactivity. So now optimizing requests sent to the server becomes as simple as defining them!

What's next on our way

In next releases we plan to add full support of named queues and possible implementation of the 3.3.x ignoreDupResponces feature(not ready for now as we rely at JSF script during updates and can't skip the update currently). Also we will discuss possible benefits and implementation ways of logical queues - which will not just pass the request to common queue with additional parameters but preprocess them in local logical queue before.

• Richfaces 4 queue requirements page

• RichFaces 4 reference guide draft

• richFaces-showcase demo

I finally got some free time and read the new JSF 1.2 Components book written by Ian Hlavats and I wanted to share my impressions with you.

Very first look

When I was done with the first chapter I decided that I was reading a book which is written for beginner JSF GUI developers. Perhaps they learned some very high level basics of what JSF is and need to get quick overview of component libraries which exist in the ecosystem. It seemed the author almost didn’t care about the JSF lifecycle and some other architectural points of JSF. At first Ian just describes how to create the pages using standard components. That chapter is likely not interesting for the guys who have already looked at some JSF kick-start projects which exists in any IDE.

Insightful Facelets chapter for the future Facelets developer

The next chapter on “Facelets” is really cool and after reading ahead I think it’s the best chapter in the book and the main reason to buy it. Basic principles, features and advantages over JSP explained very clear in a simple way. I think the choice between facelets and JSP will be simple after reading that chapter and it would be enough to just start development without reading official documentation or any external articles additionally.

MyFaces Tomahawk and Trinidad Chapters

The Tomahawk chapter, much like the chapter on standard components is just a brief usage overview of the components. These are represented in a way, and have a set of good simple samples of usage in applications. The Trinidad chapter will be more interesting for the reader as contains not only tag a library overview but good common feature descriptions such as Ajax, skinning and client side validation/conversion. That chapter is very good as a common overview of the features and startup for reading detailed references of the library. There will be separate overview of the mistakes in the book later but the one which confused me in this chapter needs to be highlighted there – “launching the dialog window” section has a piece of code (to build list and select one the products) which completely differs from screenshot after it(just picking the color from color picker) and this is really weird.

IceFaces Chapter

This chapter also contains a good overview of the IceFaces components. In general it only lacks some coverage of Direct To Dom technique used for updates which is one of the key features of the framework. After reading the chapter I am left with many questions about the framework, but this is not the fault of the book itself. The author describes good points that need to be answered by the framework documentation before usage.

Seam, Ajax4jsf and RichFaces chapters

So now we get to the chapters I have waited for, especially since I am a core developer of RichFaces. Unfortunately the chapters were very confusing to me.

We'll start with the Seam chapter. Our beginner JSF GUI developer should now be a J2EE experienced guy. The big difference in this chapter and all the previous ones is that developer should now care about the back-end objects and services. While in the first part of the book those topics were skimmed over. It does not look good to me as the overall level of the book changed significantly.

Then I need to highlight the confusion with the information in general among these chapters. The Seam and RichFaces sections, for example, contain some pieces of core Ajax4jsf information (some of which are missing in Ajax4jsf chapter) and reading Ajax4jsf you need to divert your attention to some Seam points highlighted again. Code detail level grew significantly in this chapter and this is also the reason of some confusions and losing some points sometimes. One of the more concerning issues is that the RichFaces chapter highlights and demonstrates some bad practices. For example, like using heavy components in table columns which could result in performance issues in a real application (unless handled specifically). Also there is confusion with the data iteration components logical grouping. a4j:repeat which is a base component for all the iteration components set combined together with one of the lists and the other lists came separately. But in general, if not take into consideration that information slightly messed among the chapters and that fact that level is differs from the other book chapters – all the basic points seems covered and the reader will take good overview of the technologies after reading.

Errors

I think mistakes are the major problem with the book. It spoiled all the good impressions which could arise during reading. Many(considering the fact that it went through editing process) code snippets and descriptions contain misprints, copy and paste problems, and some problems with repeating of the same sentences again and again which makes me for example to disperse attention from the main points.

Summary

So my impressions after reading are ambivalent. The book really carries its prices as a good review for beginners. But it should not be claimed for something more. Also low level of samples details in cases where it’s really need for the understanding and the errors sometimes through the samples and sometimes through the overviews is really prevent from starring it much than 4 from 10.