I’m excited to announce the availability of RichFaces 4.2.0.CR1, our release candidate for RichFaces 4.2.0. Hot on the heels of the RichFaces 4.1 release, Richfaces 4.2 delivers some “missing” components migrated from RichFaces 3, and offers usability and API improvements for those looking to take advantage of our resource loading optimizations, and push API. Not to forget a significant number of bug fixes, and overall usability improvements.
To try out this release, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.2.0.CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.
Let’s begin our look at the RichFaces 4.2.0.CR1 release with a look at the new components: rich:contextMenu and rich:hotKey.
New Component - rich:contextMenu
The rich:contextMenu component provides hierarchical context menu system similar to those found in many desktop applications, and was widely sought after by our community with a significant number of votes in our issue tracker. I’d like to thank our loyal and persistent community for identifying the gaps in our RichFaces 3 -> Richfaces 4 migration story, and assure you that we will continue to work diligently to ease the migration process.
The rich:contextMenu itself is built on top of the existing rich:dropDownMenu implementation, making it a natural fit into the RichFaces 4 component set. The rich:contextMenu has 3 modes of operation client, ajax, and server, and integrates with the row/node selection capabilities of the rich:extendedDataTable and rich:tree components. The RichFaces showcase includes examples of each of these features.
The RichFaces 3 feature of “macrosubstituion” (client side string replacement) for the contextMenu has been so far omitted from the feature, but is being racked via jira (RF-11842). Be sure to vote for this issue if you feel it’s important to include in a future Richfaces 4 release. Likewise, be sure to file any jira issues should you have additional use-cases we’ve overlooked.
New Component - rich:hotKey
The rich:hotKey component is another ported Richfaces 3 component we are making available with our 4.2.0.CR1 release. The rich:hotKey component allows one to register a “hot key” on the page (or on a particular component) to execute some logic when the registered key-combination is pressed. This is functionality is often sought after in “heads down” data entry style applications, but is also valuable in any use case where one wants to enable “mouse free” operations. Many thanks to Ilya Shaikovsky for the pull request porting this feature to Richfaces 4.
Improvements - a4j:push
The a4j:push component has seen some attention, improving it’s usability with this release. First and foremost is our decision to turn off JMS integration by default - as of RichFaces 4.2.0, JMS integration must be explicitly turned on (RF-11892). This breaking change was introduced to ease the on-boarding of new users with push technology, as the component now works in both Servlet and EE containers out-of-the-box. Those who want to leverage the benefit of JMS integration will now have to explicitly enable it with the contextParam in your web.xml:
org.richfaces.push.jms.enabled true
Another usability improvement has been the introduction of on-demand topic creation (RF-11483). The significance of this change is that you no longer need to implement a ServletContextListener, initializing your topics at application startup time. Instead, topics will be created on first access. Similarly, the push component itself will be initialized on first use.
However, when using push outside of the FacesContext threads (JMS-end points, timers, etc.) you will need to continue initializing push on startup, so that the push feature has a reference to the right contexts when called from those external threads. To do so, enable the context-param org.richfaces.push.initializeOnStartup in your web.xml.
Lukas Fryc has a great blog post giving an introduction to using the 4.2 a4j:push technology. We’ll have the Developer Guide updated with a complete description of using this feature in time for the 4.2.0.Final release.
Resource Loading
With our 4.1 release, we introduced our resource loading optimisation feature. Unfortunately, we conflated the ideas of resource mapping, with resource minification/packaging. There are valid use cases to enable resource mapping, while requiring neither minification, nor packaging, such as providing your own patched version of jsf.js, or even replacing the packaged version of jQuery with your own.
To better reflect these use cases, we re-worked the context-params that enable the feature, renaming them to clarify their purpose, and introduced a resource mapping file (independent of the mapping file used with resource packaging - RF-11909). The 4.1 context-params map into the new 4.2 context-params as follows:
RichFaces 4.1 context-param | RichFaces 4.2 context-param | |
---|---|---|
org.richfaces.resourceMapping.enabled | → | org.richfaces.resourceOptimization.enabled |
org.richfaces.resourceMapping.compressedStages | → | org.richfaces.resourceOptimization.compressionStages |
org.richfaces.resourceMapping.packedStages | → | org.richfaces.resourceOptimization.packagingStages |
Note: The 4.1 context-params will work in 4.2, they will be removed in a subsequent release
The significance of this, it that application developers can now create a simple mapping file, overriding the individual entries of the default mapping file without having to re-execute the whole packaging/minification process.
Look forward to some forthcoming blog posts detailing how to make use of the Resource Loading optimisations in RichFaces. We’ll also have the docs updated in time for the 4.2.0.Final release.
Skinning Improvement - Rounded Corners
A pull request from a community member (Adrian Gonzalez) enables round corner support in the RichFaces skins (RF-11848). This feature takes advantage of the border-radius CSS 3 property, and so will only work with compatible browsers - with a safe fall back to square corners in browsers that don’t support this CSS property. The screenshot below demonstrates what the RichFaces showcase looks like, with round corner support enabled.
To enable round-corner support for your skin set the panelBorderRadius property of your skin to the desired border-radius value.
Note: panelBorderRadius is not used in any of the out-of-the box 4.2 themes
Miscellaneous fixes
A number of other notable improvements include:
- jQuery upgraded to v1.7.1 (RF-11838) ** Fixes the “event.layerX and event.layerY” deprecation warning in Google Chrome
- RichFaces available via maven central (RFPL-1800) ** No longer is it required to define the JBoss nexus repository in your settings.xml to consume richfaces maven artifacts
- Mobile tweaks ** improvements to the mobile getting started guide ** component specific usability improvements
- Spring Webflow compatibility (RF-11806)
- a4j:actionListener example in the showcase ** omitted in our initial release of the showcase, an example of a4j:actionListener usage has been added to the 4.2 showcase
- Build improvements ** The dependency management across all the projects’ poms has been cleaned up and centralized
Moving forward
With RichFaces 4.2.0.CR1 in the hands of our community, we look forward to hearing your feedback on this release, particularly if we missed any regressions. Should 4.2.0.CR1 be well accepted by our community members, we will release RichFaces 4.2.0.Final as a simple respin of CR1. In the mean time we will work on getting our 4.2 docs finalized, including an effort to fill in the missing attribute descriptions of our tag library documentation (VDL doc).
Looking beyond 4.2, we will consolidate many of the great ideas brought forward in our “4.3 and beyond” planning discussion into a project roadmap, and start some prototyping to spearhead our new initiatives.
Share this post
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Pinterest
Email