PrimeFaces 5.0 is going to be released any day now - most likely tomorrow (May 5, 2014). Çagatay Çivici, Thomas Andraschko, and a few others invested a lot of work in the new version: The source code repository lists more than a thousand commits since the last version, PrimeFaces 4.0, which in turn has been released only half a year ago. So it's time to look what's happened since October 3, 2013.
Improved JSF 2.2 support
While PrimeFaces 4 already offered decent JSF 2.2 support, it still left room for improvements. For instance, <p:ajax> now allows you to send an AJAX request with a certain delay (instead of sending it immediately). The same applies for the components that send AJAX requests.
From my (slightly subjective) point of view, the most important JSF 2.2 additions are the features needed by BabbageFaces. The JSF 2.2 standard allows for a very fine-grained update of the DOM tree. BabbageFaces uses the advanced commands of JSF 2.2 to reduce the amount of network traffic. However, PrimeFaces itself doesn't need most of the commands defined by the JSF standard, hence they didn't implement them in PrimeFaces 4. Thomas Andraschko added the missing features. As far as I know, PrimeFaces itself still doesn't make use of them, but it might improve compatibility to JSF frameworks that can be combined with PrimeFaces (BabbageFaces being a prominent example).
ExceptionHandler
That one's a major improvement. By default, JSF doesn't do exception handling gracefully. Exceptions thrown in an AJAX request are virtually "swallowed". The required action doesn't take place, but there's no hint something went wrong - except the log file on the server, which is often missed even by programmers. From the user's perspective, the application simply freezes.
PrimeFaces 5 exception handlers fix this. The new <p:ajaxExceptionHandler> gives you very fine grained control on which exception you want to take care of and how to deal with them. Other than established solutions such as the FullAjaxExceptionHandler of OmniFaces or the error page entries in the web.xml the PrimeFaces 5 exception handler works on a per-form-basis. This means every view of your application can deal with exceptions in a different way. If you want your exceptions dealt with in a uniform way, put the exception handler into a template.
New components
- Cache: Processing a JSF view takes some time. You can speed up your application by caching parts of the rendered JSF page.
- It's kind of surprising there's wasn't a ScrollPanel in PrimeFaces before 5.0. It's one of the components you need every once in a while. In theory, it's simple to implement an area that's automatically added a scroll bar if it doesn't fit in the available space: surround it with a DIV, add some CSS and you're done. The ugly truth is this approach isn't compatible in every browser. The ScrollPanel component adds scroll bars in a cross-browser compatible way.
- Spotlight. This is just what the name indicates: once you activate a spotlight, a certain area of the screen is highlighted, while the remaining screen is darkened. The effect gives the highlighted area a strong focus.
- DataScroller: This component makes it simple to implement lazy loading. By default, browsers load and render the entire page, even if it's much larger than your screen. This can cause long and unnecessary waits. The data scroller delays rendering parts of the screen that are out of the visible area. When the user scrolls the page, the data scroller loads and renders dynamically the HTML code needed.
- SelectManyMenu and SelectOneListbox are similar to Mojarra's SelectManyManu and SelectOneListBox, but allow for rich content. For example, you can add images to the list items.
Improved components
A lot of work went into improving the data table. For instance, you can now define frozen columns (i.e. columns that do not scroll when the table is scrolled). Rows can be reordered by simply dragging them to another location, columns can be hidden and shown by the user and filtering has been improved.
The Charts have been overhauled. That's good news: albeit PrimeFaces 4 offered a variety of different charts, they're not as flexible as you want them to be. For instance, line charts used to behave a little weird if the X-axis is a date. They reordered the data in alphabetical order - making the entire chart useless in my current project. PrimeFaces 5 fixes this, and as things go, the date example is even one of the examples on the show case.
There's a caveat: PrimeFaces 5 introduces a new set of charts, marking the old charts deprecated. So you'd rather migrate your existing charts before they are removed from PrimeFaces in a future version.
Calendars can now display an input mask, showing the correct format of the date to the user. The nice thing about the calendar mask is it suffices to enter the digits - a feature demanded by many users who prefer to use the numeric keypad exclusively when dealing with large amounts of numbers.
Bringing bean validations to the client
That's a small but important improvement. Until recently, every bean validation annotation was processed on the server. Starting with PrimeFaces 5, some annotations are already checked on the client side. Currently, this feature checks mandatory fields (annotated by @Size(min=...) or @NotNull) and the maximum length of input fields. Read the full story at the PrimeFaces blog.
Compatibility to DeltaSpike
One of the committers of PrimeFaces, Thomas Andraschko, is also a committer on DeltaSpike, so some effort went into making PrimeFaces 5 and DeltaSpike work smoothly together.
Performance
Performance is always a hot topic. So it's not to big a surprise the performance of PrimeFaces 5 has been improved, especially on the server side.
The client side has also been improved. JSF programmers are very aware of memory leaks on the server, but that doesn't mean there aren't memory leaks on the client, too. In fact, many PrimeFaces widgets were never released in AJAX applications, forcing the browser to acquire more and more memory. This affects even heavy-weight widgets such as <p:dataTable>. The days most clients have an abundance of memory, so the error caught the developers' eyes only recently. PrimeFaces 5 detaches client widgets properly even when they are in a container that's being replaced by an AJAX request.
Compatibility
PrimeFaces 5 is compatible to JSF 2.0, JSF 2.1 and JSF 2.2. Today I've also run a quick test with Liferay 6.1. Apart from a minor AJAX issue (you have to switch off AJAX if your portlet switches to a new JSF page), everything ran fine.
Conclusion
PrimeFaces 5 contains a lot of improvements and bug fixes - more than this article can cover. Actually, the current version feels more like evolution than revolution. That's a good thing: JSF 2.2 was a big chunk to swallow, so it's good the developers concentrated on polishing the components that already existed. Nonetheless, there are improvements that may convince you to update soon. In my eyes, that's the AJAX exception handler and - at least for those who use the chart components - the overhauled chart library.