Tuesday, April 17, 2012

RichFaces 4.2.1.Final Release Announcement

We’ve released RichFaces 4.2.1.Final – the first micro release for the 4.2 release train. Since the CR1 release we’ve primarily addressed bugs with the Richfaces showcase and the RichFaces archetypes. CR1 itself focused on bug fixes and stability improvements throughout the framework.

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.1.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

What’s in 4.2.1.Final?

One noteworthy issue to take note of:

  • [RF-11940] – Our ajax push component (a4j:push) was not receiving pushes from the server on Android devices. We identified a bug in the Atmosphere framework which powers our push technology, a bug which we fixed and pushed back upstream (OSS for the win!).

Be sure to check out the 4.2.1.CR1 release blog for a more complete picture of what we addressed with this micro release.

New with this release, we are once again deploying the showcase on new infrastructure. The OpenShift Express service has been unified with OpenShift Flex to deliver a single service now simply referred to as OpenShift (see this FAQ entry). The end result for us is a simplified deployment and management console, and an easier ability to host multiple applications.

Moving Forward

We’re currently focused on improving the JSF testing and RichFaces mobile stories. However we’ll shortly begin our 4.3.0.M1 sprint which will focus on MyFaces compatibility issues. Concurrent to all this, we will working in the RichFaces Sandbox to deliver our next-generation component set. Should any of the above initiatives appeal to you, feel free to get involved and help move the project forward!


Wednesday, April 4, 2012

RichFaces 4.2.1.CR1 Release Announcement

We’ve released RichFaces 4.2.1.CR1 – the first candidate release for the first 4.2 micro release. This release comes with initial support for rapid component development with the CDK and jRebel, and a new archetype demonstrating (among other things) a mobile RichFaces application,. For the most part however, this release focuses on bug-fixes and stability of the components and framework.

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.1.CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Kitchensink Example

Since the 4.2.0.Final release, we’ve included a new sample application: the RichFaces kitchensink quickstart (also available as an archetype). This is example application demonstrates key pieces of the Java EE stack, with a JSF/RichFaces frontend. We have it currently deployed to openshift if you want to see it in action. Be sure to check out this example with your mobile phone, to see the kind of mobile application you can build with RichFaces (complete with client side validation, and ajax push!)

Rapid component Development

Another new initiative that made its way into this release is the work we’ve been doing to support rapid component development with the CDK and jRebel. We’ve included the necessary jRebel configuration in our component projects (RF-12090) to enable jRebel to hot reload the classes generated by the CDK. See Lukas’ blog post for details on how you can get this working seamlessly within eclipse with JBoss tools.

Highlighted release notes

Specific components addressed include the rich:extendedDataTable, rich:contextMenu, and a4j:push:

  • ExtendedDataTable
    • [RF-10754] – extendedDataTable: two or more components placed on the page causes horizontal scroll to disappear
    • [RF-11948] – rich:extendedDataTable create an onready event to trigger javascript interactions after the EDT has been initialized
  • a4j:push
    • [RF-12013] – Deadlock in push component
    • [RF-12072] – Push: add onsubscribed event
  • rich:contextMenu
    • [RF-11936] – rich:contextMenu activation is possible outside of tree nodes
    • [RF-11971] – rich:menuItem onclick return value ignored
    • [RF-12042] – Metamer: rich:contextMenu doesn’t disappear after clicking out of the menu in IE9 and Google Chrome
    • [RF-12043] – rich:contextMenu isn’t rendered correctly in IE 9 compatibility mode
    • [RF-11996] – rich:contextMenu on several rows in extendedDataTable

Overall, areas such as event handling, validation, messages, and browser compatibility were addressed:

  • Events
    • [RF-10941] – a4j:command* components misses default behavior event
    • [RF-12091] – rich:dataScroller scrollListener not documented
    • [RF-10968] – Tree: treeSelectionChangeListener and treeToggleListener do not work
    • [RF-12007] – AbstractPanelMenuGroup.getChangeExpandListener is not used
  • Validation/messages
    • [RF-7351] – Regression: “messages: globalOnly does not work properly”
    • [RF-11978] – Graph Validator – does not mark context to fail validation
  • Browser compatibility
    • [RF-12026] – Javascript error in AjaxRequests on FireFox “invalid ‘in’ operand event”
    • [RF-11884] – Multiple Errors with IE8/9

The RichFaces showcase saw some improvements, including some mobile specific fixes:

  • Showcase
    • [RF-11872] – Mobile Showcase and a4j:region demo: submit button doesn’t respond on the first click
    • [RF-11905] – shutdown of the JBoss AS with showcase deployed throws DB error
    • [RF-12048] – Showcase: Change the password for JMS guest connection
    • [RF-12051] – Showcase: simplified Push CDI sample which wouldn’t use subtopics

Lastly, a few fixes I couldn’t fit into any of the above categories:

  • Miscellaneous fixes
    • [RF-11977] – Multiple fileUpload controls on the same page do not work
    • [RF-12093] – ResourceServlet can’t handle resources outside of specific libraries
    • [RF-12052] – rich:TabPanel – HTML comments should be supported inside the tabPanel

Next steps

Our crack-QE team has uncovered some regression in the CR1 release with their extensive test suite. We’ll address these issues with the 4.2.1.Final release, but be sure to give the CR1 release a spin to check for any issues we may have overlooked. Of course, concurrent to this micro release, we’re hard at work on some brand new stuff for RichFaces 4.3 (see the relevant planning discussion for details).


Thursday, February 23, 2012

RichFaces 4.2.0.Final Release Announcement

Richfaces 4.2.0.Final is now available for download! A quick follow on to our 4.1 release, Richfaces 4.2 delivers some “missing” components migrated from RichFaces 3, and provides usability and API improvements for resource loading optimizations and the push API. Documentation was a huge effort for this release; we are delivering an updated and complete VDL taglib doc, along with our more well established Developer Guide, and Components Reference.

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.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

What’s new in Richfaces 4.2

For details on what’s new in 4.2, have a look at the 4.2.0.CR1 release announcement, where we cover:

  • New components (ported from RichFaces 3)
  • Push (a4j:push) API changes
  • Resource Loading improvements
  • Skinning changes
  • A number of miscellaneous fixes.

Additionally, Lukas Fryc, has a few blogs out with further details on the developer impact of some of these features:

Looking Ahead

It’s now time to buckle down and focus on 4.3/4.Future efforts. The themes we will be focusing on are narrowing down to:

  • Continued improvement of the RF 4 core components
    • Further feature migration from RichFaces 3 (as required)
    • Bug fixes, performance enhancements
  • A re-work of our testing infrastructure
    • Bridge the gap between what we do to test our framework, and what devs do testing their applications
  • A new set of components
    • Improving our turnaround time, by leveraging existing javascript “widgets”
  • CDK improvements
    • Further simplifying the process for creating new components, while improving the turnaround time of component development

If you are interested in these efforts, and in the details behind them, chime in (or just follow along) to our RichFaces 4.3/4.Next planning discussion.


Wednesday, February 8, 2012

RichFaces 4.2.0.CR1 Release Announcement

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:

<context-param>
    <param-name>org.richfaces.push.jms.enabled</param-name>
    <param-value>true</param-value>
</context-param>

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
  • 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.


Tuesday, December 13, 2011

RichFaces 4.1.0.Final Release Announcement

I’m thrilled to announce the release of RichFaces 4.1.0.Final. It’s been a long road from 4.0 to 4.1, with a significant train of milestone releases along the way. The journey was worth it though, with a significant 4.1 release building on top of the successful 4.0.0.Final release, providing: additional components migrated from the RichFaces 3 component set, altogether new components, and significant enhancements to the framework feature set.

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.1.0.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Let’s dive in, and look at some of the details of what’s new in RichFaces 4.1!

h3.New Components

We’ve delivered a number of new components in this release:

Not only have we migrated forward more RichFaces 3.x components, but we’re also providing an altogether new component – the notify component – put together by Bernard Labno, a RichFaces community member.

Mobile Compatible Components

We’ve leveraged HTML 5 and CSS 3 to create a set of resources that make the existing RichFaces components mobile compatible. Check out the results yourself in our mobile showcase with your webkit-based mobile phone, (or checkout the mobile showcase directly with your desktop browser).

We’ve put together a comprehensive guide detailing how you can take advantage of this approach with your own applications, and deliver a modern mobile application today – leveraging your existing skillset and investments in both JSF and Richfaces.

Not all the components make sense in a mobile environment, and not all mobile browsers are equally capable. Be sure to also take a look at our mobile design document, outlining the choices and compromises we had to make.

Showcase

Along with this new mobile face, the Richfaces showcase has undergone a number of additional significant changes.

We’ve deployed the showcase to OpenShift, Red Hat’s PasS offering. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

We’ve also included samples for the new components listed above, as well as a rich:push component sample, keeping it straightforward to incorporate advanced RichFaces components in your application. Lastly, a number of bug fixes and simple improvements throughout the showcase have overall improved the user experience of the showcase itself.

Individual component improvements

I’d like to single out a few component enhancements from this release:

rich:push
Push has been de-coupled from JMS, allowing RichFaces users to take advantage of push technology in non-JMS (ie. servlet) environments
A CDI API has been provided for firing push events – aligning the push component with the standardized Java EE programming model
rich:fileUpload
Some events that were missing from the 4.0 release have been added, including the onclear event
drag and drop
A bug with dynamically rendering of drag sources and drop targets has been resolved, improving drag/drop functionality in components like the rich:tree
rich:extendedDataTable
For those creating RichFaces skins, you’ll be happy to hear we replaced the cellpadding and cellspacing attributes of the extended datatable with CSS equivalents, allowing skins to override the values

For a complete listing of issues resolved, refer to the release notes of each of the milestone releases: 4.1.0.M1, 4.1.0.M2, 4.1.0.M3, 4.1.0.M4, 4.1.0.CR1, 4.1.0.CR2, 4.1.0.Final

Resource packaging

Another great feature with this release is the Resource packaging and minification. An absolute necessity when developing for mobile applications, this feature can provide performance improvements to your desktop applications as well by dramatically reducing the number of javascript and CSS files the browser client has to download. Read the docs to see how you can activate this for your applications.

For those looking for the RichFaces 3 LOAD_NONE capability, you can use this resource minification configuration to achieve the same results.

Source hosted on github

A significant achievement early in the 4.1 development process was the migration of our source code version control system from svn to git, specifically hosted on github.com. We noticed significant advantages to using git, both within our team, and in our collaboration with community members. Git’s ability to enable a sophisticated workflow, and encourage community contribution in the form of pull requests has made “bit management” a pleasurable task.

Other noteworthy items

It’s worth pointing out that RichFaces 4.1 ships with an updated jQuery release (v. 1.6.4). Keeping the jQuery release version up-to-date facilitates RichFaces inter-operability with other jQuery plugins.

RichFaces 4.1 works with a number of modern browsers, however it currently requires Internet explorer 9 to be run in compatibility mode, due to an upstream mojarra issue.

Documentation

Lastly, I’d like to remind everyone of the availability of the RichFaces documentation:

These docs are a great resource detailing how to make use of the RichFaces framework in your application. They are however an ongoing effort, with some specific areas that need improvement. Specifically we need to flesh out the descriptions of the VDL tag library doc (note: the attribute listing is complete), and we need to vet the migration guide. This is a great way to get involved, should you want to contribute to the project!

Looking Forward

In a recent blog post, I laid out a strategy for the future of the RichFaces project, and extended an invitation to all who would like to have a say in future directions in our development forum. While RichFaces 4.1 undoubtedly provides some great fixes and features, we are excited about the future direction of the project, and what we can offer moving forward!


Friday, December 9, 2011

State of the RichFaces

With a RichFaces 4.1.0.Final release on the horizon, now is a good time to talk about the future of the project. Let me start by announcing that I will be taking over from Jay Balunas as lead of the RichFaces project. Jay has been a long-time shepherd of RichFaces from within JBoss, and has had a direct hand in making the project such a great success. Jay has been a terrific mentor and while he is stepping down as the project lead, he will continue to stay involved, sharing his insight and experience with the Richfaces team. He will just no longer get the final word ;)

Moving forward, I would like to see the project continue to focus on the key strengths that have made RichFaces such a great project to be involved with: innovation, open standards, community, and quality.

Innovation


RichFaces has long been the place to come for JSF innovation. Never content to simply provide a JSF component set, the RichFaces project (together with other JBoss projects) has always aimed to provide developers with a complete JSF framework for developing applications. Some of these innovations include:

Open Standards

Richfaces has played a significant role in improving the JSF specification with contributions to JSF 2.0, particularly in the area of ajax integration. RichFaces also aims to improve the standards story by integrating JSF with other Java EE standards in some of the same innovations mentioned above:

  • Client side validation brings Bean Validation into the client environment
  • The push component couples JMS messaging with our JSF component set
  • The push component also leverages CDI, providing building on the standardized Java EE programming model

Community

RichFaces is also very much a community oriented project. Both our development and planning efforts are done out in the open, with an open door to anyone who wants to help out. Some of the ways we actively work to facilitate community interaction include:

Quality

RichFaces is a very well tested project, with a dedicated QE team that continually writes new tests for the framework, and ensures that existing tests continue to pass in their automated runs. Look forward to some upcoming blog posts, where we will expand on our testing strategy, and speak to the industry leading role JBoss is taking with projects like Arquillian, JSFUnit, and how we build on that with RichFaces. This all comes together in a robust, enterprise-ready platform on which you can develop and deploy your applications.

Moving Forward

Moving forward we plan to keep up this pace of innovation with our 4.Next efforts. The existing component set is crucial to the project, and will continue to see new improvements and additions – but we need a new vehicle to deliver new components faster and more effectively. We would like to be able to better leverage the mountain of work done in other OSS projects in the javascript component space, and facilitate contributions from prospective contributors looking to implement their own “critical components”. To this end, we are proposing the addition of another component set in the RichFaces project.

This new component sub-project will leverage existing javascript code where possible, either directly, or by composing them into new components. Where use cases require, we will continue to develop new components, contributing back to upstream javascript projects wherever possible. This idea is currently at a proposal stage, with a proof-of-principle demonstrated my recent CDK blog series. Join us in the developer forums, as we work out the details of how to build this next-generation component set.

Thanks to all of you for your interest and contributions to the project, feel free to ping me in the forums, IRC (in #richfaces), twitter or anywhere for that matter should you want to discuss how you can contribute to the project, and help shape it into what you need it to be!


Tuesday, December 6, 2011

RichFaces 4.1.0.CR2 Release Announcement

We are announcing the release of RichFaces 4.1.0.CR2, a second release candidate for RichFaces 4.1. We had a couple of regressions that were introduced in the 4.1.0.CR1 release that we’ve addressed in the with this CR2 release. The expectation is that CR2 will be re-tagged and released as 4.1.0.Final, provided no blocking issues are found. Our QE team has done a great job running their test suite against this release, but I encourage as many community members as possible to download the CR2 release, and make sure it’s “up to snuff”!

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.1.0.CR2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Noteworthy changes

In addition to addressing the above regressions, our CR2 release has addressed a couple other noteworthy issues.

  • showcase tweaks: improving the user experience on both desktop and mobile
  • archetype improvements: including the addition of an option for creating a mobile project
  • skins: warning messages had an unreadable color on a white background – (warningColor) [RF-11673]
  • rich:inplaceInput: a fix for client side validation [RF-11633]
  • rich:dataTable: a fix for a regression effecting component decoding [RF-11675]
  • rich:calendar: a fix for a regression selecting dates in the popup [RF-11677]
  • rich:pickList: a bug converting java arrays when used as backing beans [RF-11680]
  • rich:fileUpload: A bug where the list of files in the event omitted the submitted files [RF-11744]
  • rich:extendedDataTable: removed cellpadding/cellspacing from EDT, replaced with appropriate CSS [RF-11759]

Please test drive this second release candidate, and give us your feedback in either the forums or with our issue tracker. We’ll soon have a 4.1.0.Final release we all can be proud of, for the work we put into it as a community!