Thursday, February 28, 2013

RichFaces 4.3.1.CR1 Release Announcement

RichFaces

The first candidate release of RichFaces 4.3 (4.3.0.CR1) has been released. This micro release addresses some bugs present in the RichFaces 4.3.0.Final release, and offers some improvements on the new features introduced in that same release. Have a look at the 4.3.1.CR1 Release Notes for a complete listing of what has been included in this release.

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

Concurrent testing efforts

Normally we leave RichFaces releases in our Nexus staging server until the RichFaces QE team has fully verified the release. With this release however, we are trying something new.

We have promoted the RichFaces 4.3.1.CR1 artifacts out of staging having only undergone a smoke test. In this way we are enabling the community to try out the latest fixes concurrent to our execution of our extensive automated test suite, and the remainder of our QA process.

So please do take this candidate release out for a spin, and report any issues you uncover so we can address them before the 4.3.0.Final release.

Friday, February 1, 2013

RichFaces 4.3.0.Final Release Announcement

RichFaces

I’m very excited to announce the availability of the final release of RichFaces 4.3 (4.3.0.Final). This release is minor in version increment only, as it packs quite a significant number of features and improvements. We’ve covered many of these features in blogs already, we’ll summarize them again here, and provide links to where you can find additional details.

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

New components

We’ve delivered some new components with this release. These are components that were originally contributed by Bernard Labno via the RichFaces Sandbox. The new components we shipped are:

  • <rich:focus> – used to manipulate the cursor focus on a page. The component is integrated with the JSF life-cycle to enable validation-aware focus capabilities.
    Blog Read the rich:focus component blog post for more details.
  • <rich:placeholder> – pre-fills form inputs with text, similar to the HTML 5 placeholder attribute.
    Blog Learn more about it in the rich:placeholder component blog post.

New Features

Aside from the new components, a number of existing components have seen some significant feature additions. The <rich:extendedDataTable> for instance has added support for built-in sorting and filtering, and table-state saving.
Blog We have a blog dedicated to the EDT improvements in RichFaces 4.3.

New with RichFaces 4.3 is the ability to define child toggle panels with the <a4j:repeat> tag. This offers developers additional flexibility when defining child toggle panels when <c:forEach> is insufficient.
Blog Check out the Dynamic Panels with a4j:repeat blog for more details.

Testing

Automated testing has always been central to RichFaces. We have a great QE team behind the framework that works hard to help us deliver solid releases. But with RichFaces 4.3 we’ve taken our automated tests to the next level.

We’ve developed the Arquillian extensions Warp and Graphene to enable us to author real tests, running in real containers, with real browsers. Through the magic of Arquillian and Shrinkwrap, these tests are still fast both to author and to execute.
Blog Read more about it in this deep dive to testing in RichFaces 4.3.

CDK improvements

Early on in our RichFaces 4.3 efforts we delivered a number of improvements to our Component Development Kit (CDK) which we used throughout this release to reduce our developer turnaround time in creating new components and features. In addition to enriching the CDK templating language, we introduced an incremental build feature in the CDK. This incremental build has proven to be so beneficial that is one of the primary drivers behind the RichFaces 5 build redesign.

Blog Refer back to this blog for further details on Incremental build with the RichFaces CDK

Bug fixes

With so many shiny new features to look at, it would be easy to overlook the number of bugs fixed in the release. In total 242 issues were addressed in this release. An epic effort for an epic release!

Path forward

As I just hinted, our steps forward are on the path to RichFaces 5. We’ve already started working on the new consolidated RichFaces 5 repository. Feel free to comment with where you’d like to see the project head in RichFaces 5 in the RichFaces developer forum thread.


Monday, January 28, 2013

Dynamic Panels with a4j:repeat

RichFaces

With the imminent 4.3.0.Final release of RichFaces, we will be providing developers with the ability to dynamically create <rich:togglePanel>, <rich:accordion>, and <rich:tabPanel> panel items dynamically with the <a4j:repeat> tag.

<a4j:repeat> vs. <c:forEach>

Creating the above panels from a backing bean list has always been possible with RichFaces 4 using the JSTL <c:forEach> tag, so why have we bothered adding support for creating such panels with the <a4j:repeat> tag? The answer to that requires an understanding of when the JSTL tags are evaluated during the creation of the JSF component tree, and subsequent page render:

TL;DR: JSTL tags are evaluated during the compilation of the Facelet, during the construction of the component tree, whereas <a4j:repeat> is evaluated during the render phase of the JSF life-cycle.

For a great/detailed explanation of the JSTL tag / Life-cycle interaction, I’ll refer you to this blog post.

So if you are currently using the <c:forEach> tag to define dynamic child toggle panel items, and are noticing an issue on post-back when the list backing the panel items may have changed, be sure to try using the tag instead.

Using the <a4j:repeat>

Refer to the showcase snapshot for examples of using the <a4j:repeat> tag with the above listed family of toggle panel items:

The 4.3 release

RichFaces 4.3.0.CR2 is currently available, and RichFaces 4.3.0.Final will be available shortly. Please take the time to take try out the <a4j:repeat> tag to define relating toggle panel items, and give us your feedback for the new features and bug fixes via the RichFaces forum or issue tracker.


Friday, January 25, 2013

RichFaces 4.3.0.CR2 Release Announcement

RichFaces

The second milestone release of RichFaces 4.3 (4.3.0.CR2) has been released. This release candidate for the RichFaces 4.3 is an incremental release on top of the previous release candidate (4.3.0.CR1), providing a few bug fixes and documentation enhancements.

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

Behaviour change for <rich:notify>

The RichFaces notify* components did not previously escape message content. This can lead to a security vulnerability in your applications, so we’ve changed the notify* components to escape message content by default, and provided the escape attribute to disable escaping of the message content.

If you previously had HTML content in your notify* components, you will need to add the escape=false attribute to achieve the same behaviour as in previous RichFaces releases.

Moving forward

We’ll again let RichFaces 4.3.0.CR2 bake in the community for a few days. Be sure to try it our with your applications and report any regressions you should come across that may have been overlooked by our QE team. We are aiming to have a final release out next week.


Tuesday, January 22, 2013

What's new with the RichFaces extendedDataTable

RichFaces

The upcoming 4.3 release of RichFaces will offer the RichFaces community a number of improvements to the extendedDataTable. These new features include:

  • Built-in sorting and filtering
  • External table state saving
  • A number of bug-fixes

Built-in sorting and filtering

The RichFaces 4 extendedDataTable (EDT) has always had the ability to sort and filter columns, but required the developer to define the sort and filter controls themselves, then manually invoke the required operations on the back-end. While not difficult to do, a lot of boiler-plate code was required for what is in fact a common operation. With RichFaces 4.3 we’ve resolved RF-8125 that tracked a long standing request to port the built-in search capabilities form the RichFaces 3 EDT to RichFaces 4.

Built-in sorting/filtering is currently only available in the extendedDataTable component. We will add support to the dataTable component in a subsequent release.

Built-in Sorting

Implementing sortable columns in the EDT is now as simple as adding the sortBy attribute to your EDT column, and the sort controls will automatically be generated and linked to the internal sorting mechanism. To influence how the sorting is performed, add the comparator attribute to your column, and the comparator defined there will be used for the sort.

Refer to the RichFaces 4 Component Reference for additional details on using the built-in and external sort controls.

If you require additional flexibility, and prefer to implement your own sort controls, set the sortType=custom attribute, and the built-in sort controls will not be rendered. Built-in sort controls can be disabled altogether by setting the web.xml context param org.richfaces.builtin.sort.enabled to false.

Built-in Filtering

Similarly, taking advantage of the built-in filter controls is also straightforward. Define the filterValue attribute on the column to be filtered, then define either a filterExpression or filter attribute to implement the filter logic. When the attributes are present an input element will be displayed in the column header. Simple value conversions are performed implicitly in the EL of the filterExpression or explicitly in the filter implementation.

Refer to the RichFaces 4 Component Reference for additional details on using the built-in and external filter controls.

Further control over the filter controls can be achieved by setting the filterType=custom attribute, and implementing your own filter controls in the back-end. Built-in filter controls can be disabled altogether by setting the web.xml context param org.richfaces.builtin.filter.enabled to false.

ExtendedDataTable State Saving

The EDT has had another RichFaces 3 feature ported forward: table state saving. With the resolution of RF-10442, application developers can add the tableState attribute to their EDT components, providing a value-binding to a bean String property that can be used to store the state of the column width, sequence, sorting, and filtering of the EDT. The table state is stored in a JSON string format, and is easily stored in a data base for later retrieval.

Bug fixes

In addition to the above feature additions, the EDT has seen a number of bug fixes in the 4.3 release. These fixes include:

RF-10154
UIDataAdaptor vs. UIData visitTee small difference
RF-10799
EDT – attribute @clientRows missing in taglib
RF-11382
Datatable and ExtendedDatatable evaluate value attribute even if rendered=false
RF-11776
rich:extendedDataTable columnsOrder attribute is not working
RF-12236
showcase – rich:extendedDataTable – re-sizing columns breaks horizontal scrolling
RF-12450
Collapsible subtable toggler not rendered
RF-12611
rich:dataTable doesn’t call restoreState() on a row-level composite component
RF-12639
rich:extendedDataTable inside rich:tab: The columns which are not frozen are not rendered after switching the tab for the first time in IE 8.
RF-12659
ExtendedDataTable layout breaks when table element width set to 100%
RF-12672
Collapsible sub table: noData facet doesn’t work inside switchable panels
RF-12684
The last page shows rows from the page before if rich:collapsibleSubTable is included in rich:dataTable with rich:dataScroller.
RF-12691
extendedDataTable: Header facet render problem in RichFaces 4

The 4.3 release

RichFaces 4.3.0.CR1 is currently available, having undergone our extensive QA process, and a 4.3.0.CR2 release will be available shortly. Please take the time to take the extendedDataTable for a spin with this release, and give us your feedback for the new features and bug fixes via the RichFaces forum or issue tracker.


Thursday, January 17, 2013

RichFaces 4.3.0.CR1 Release Announcement

RichFaces

The first candidate release of RichFaces 4.3 (4.3.0.CR1) has been released. This release candidate for the RichFaces 4.3 release doesn’t add any new features, rather it polishes, documents, and showcases the many new features added in the earlier 4.3 milestones (4.3.0.M3, 4.3.0.M2, 4.3.0.M1).

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

Documentation updates

If you are interested in taking advantage of some of the new feature additions described in the earlier milestone release blogs, be sure to check out the updated RichFaces 4.3.0.CR1 documentation, and the showcase snapshot which demos the latest updates to the showcase.

Some of the documentation highlights include:

Also, check out the code samples in the showcase:

Bug fixes

Most of the bug fixes in CR1 centered around the new 4.3 features. These bug fixes include:

Validation fixes

  • RF-12700 – LongRangeValidator client-side messages differs from server-side ones on MyFaces
  • RF-12669 – Autocomplete: client side validation for custom validators doesn’t work

Select component fixes

  • RF-12608 – pickList without collectionType results in failure to lazily load
  • RF-12692 – rich:select – unknown validator SelectLabelValueValidator

New component fixes

  • RF-12650 – rich:placeholder: when @rendered=false the placeholder is still rendered
  • RF-12668 – rich:focus – stops to work when containing form is re-rendered by another form
  • Iteration component fixes
  • RF-12662 – Showcase – rich:extendedDataTable – Built-in sorting and filtering – ELException when text filter value provided instead of expected numbers
  • RF-12691 – extendedDataTable: Header facet render problem in RichFaces 4
  • RF-12672 – Collapsible sub table: noData facet doesn’t work inside switchable panels
  • RF-12673 – Collapsible sub table: filtering doesn’t work inside switchable panels
  • RF-12684 – The last page shows rows from the page before if rich:collapsibleSubTable is included in rich:dataTable with rich:dataScroller.
  • RF-12714 – Showcase and rich:dataTable: sorting in Arrangeable demo doesn’t work

JSF compatibility fixes

  • RF-12670JSF 2.0 compatibility issue, NoSuchFieldError: javax/faces/component/visit/VisitHint.SKIP_ITERATION
  • RF-12693 – Mojarra fails to encode form inputs correctly when they doesn’t have name attribute

Drag and drop fixes

  • RF-12666 – Showcase – Drag and Drop with indicator – the styles do not apply for indicator when dragging over various targets
  • RF-12671 – dropTarget does not work inside dynamic tabs when switchType is ajax or server
  • RF-12703 – showcase – drag and drop – JS error with default dragIndicator

Input fixes

  • RF-11067 – rich:autocomplete popups with suggestions does not reflect the value in input
  • RF-11565 – Showcase: multiple selections in rich:autocomplete doesn’t work when ‘clicking’ is used
  • RF-12707 – rich:calendar – setValue(…) method from javascript API doesn’t work correctly

Misc fixes

  • RF-12708 – rich:jQuery: wrong VDL documentation of selector attribute
  • RF-12716VDL-doc for a4j:ajax incorrectly states that the listener method cannot accept parameters
  • RF-12709 – richfaces.js: fire ajaxcomplete event
  • RF-12705 – vdl documentation for a4j:outputPanel contains non-implemented layout="none"
  • RF-12713 – Listeners don’t work inside panels

Moving forward

We’ll let RichFaces 4.3.0.CR1 bake in the community for a few weeks. Take it for a spin, and report any regressions you should come across that our top-notch QE team might have overlooked. Hopefully we can have a final release out by the end of the month.


Thursday, December 20, 2012

RichFaces 4.3.0.M3 Release Announcement

RichFaces

The third milestone release of RichFaces 4.3 (4.3.0.M3) is now available. This 3rd and final milestone for the RichFaces 4.3 release brings in a number of huge features, including new components, some long-time outstanding feature migrations from RichFaces 3, and some significant bug fixes. Read on for some details of these release highlights, or go straight to the Release Notes for a complete list of what’s been addressed.

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

New Components

We’ve incorporated a couple of RichFaces Sandbox components in RichFaces 4.3.0.M3: the rich:focus and rich:placeholder components, created by Bernard Labno.

We will update the RichFaces Documentation with all the details of these new components in the course of our 4.3.0.CR1 preparations. In the mean time feel free to explore these components yourselves referring to the showcase snapshot samples linked to below.

rich:focus

The rich:focus component provides a rigorous means of controlling which inputs on your page have the keyboard focus. The focus manager integrates with JSF to automatically focus Inputs that fail validation.

Have a look at the demo in our showcase snapshot for an example of how to use the focus component.

rich:placeholder

The placeholder component let’s one set a “hint” that is a description of the expected value of an input component This component allows RichFaces developers to take advantage of the HTML 5 placeholder attribute functionality in all browsers, including in those browsers that don’t explicitly support the attribute.

Check out the usage examples in the RichFaces showcase snapshot to see how the placeholder component is used.

New ExtendedDataTable Features

With this third milestone release of RichFaces 4.3, we’ve ported a couple of new features forward for the rich:extendedDataTable component. Both the table state saving functionality and built-in sorting/filtering features from RichFaces 3 have been ported to the RichFaces 4 implementation on the rich:extendedDataTable. Check out the built-in sorting/filtering in our showcase snapshot sample.

The introduction of built-in sorting/filtering will have a noticeable side-effect for those of you already using sorting/filtering functionality with the rich:extendedDataTable. To prevent a “doubling up” of the controls, you will have to introduce the sortType="custom" and filterType="custom" attributes.

With RichFaces 4.3.0.CR1 we will provide a way to centrally disable built-in sorting/filtering allowing users to adopt RichFaces 4.3 without any required code changes.

Ajax improvements

A number of fixes have gone into this release in the area of RichFaces ajax, each of these issues is significant in it’s own right:

  • RF-12442 addresses the use of RichFaces with multiform JSF pages, a significant improvement for a number of use cases.
  • RF-12229 fixes broken render="@all" functionality
  • RF-12642 introduces two new events ajaxbegin and ajaxbeforedomupdate

Other Significant Fixes

In addition to the new components and features listed above, I’d like to call out a few more areas that have seen improvements:

Finally I’ll point out we’ve updated a some of the libraries on which RichFaces builds it’s functionality:

Testing improvements

With this milestone we’ve really stretched the legs of the new testing infrastructure based on the Arquillian extensions Graphene and Warp. Our so-called “Fundamental tests” (or “fun tests” for short) run in container and against real browsers and have proved invaluable in issue reproduction, isolation, and verification.

Check out these tests for yourselves and use them as an inspiration for how you can test your own JSF applications. Using this test infrastructure ourselves is helping us to nail down the required APIs and functionality, and we could use your help in ensuring we are covering as many use cases as possible.

Moving Forward

We’ve already been hard at work resolving some bugs and regressions discovered by the RichFaces QA team. These will be available in the new year as our RichFaces 4.3.0.CR1 release, and Final is just one short hop beyond that.

With RichFaces 4.3 nearly complete and under our belt, it’s time to shift focus to RichFaces 5 and all the significant changes we want to bring in with that major release. Be sure to drop by the developer forum and share your insight as to where the project should be headed.


Tuesday, October 30, 2012

RichFaces 4.3.0.M2 Release Announcement

RichFaces

The second milestone release of RichFaces 4.3 (4.3.0.M2) is now available. Another significant milestone for the project, this release incorporates a number of new features, bug fixes, and component upgrades. Read on for some highlights of the release, or go straight to the Release Notes for a complete list of what’s been addressed.

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

Community involvement

I’d again like to thank RichFaces community members for their contributions to this release. In total there are 7 community members who have contributed this milestone release! This is a number that makes me incredibly proud to share, and demonstrates how the RichFaces community is truly thriving. So together, as a community, let’s have a collective shout-out to:

Keep the pull requests coming guys!

UIRepeat support in Toggle Panels

With the resolution of RF-9443, the RichFaces increases support for the <a4j:repeat> component to dynamically define repeating child panels of components that extend AbstractTogglePanel class. This includes:

While it has always been possible to use the JSTL <c:forEach> tag to define child panel components, this did not meet all use cases, as the JSTL tags are evaluated before the component tree is built, and hence don’t play nice when the underlying data model changes without performing a full page reload. With the new support for defining child panels using the <a4j:repeat> syntax, evaluation is deferred until render time, making the child panels “truly dynamic”.

The implementation of this leans heavily on the RichFaces UIDataAdaptor, which forms the basis for all repeating RichFaces components. stay tuned for a blog demonstrating <a4j:repeat> usage to dynamically define repeating toggle panel items, and be sure to test this feature out in this milestone release, to be sure the feature meets your requirements for dynamic repeating panel components – let us know if it doesn’t!

Note: this feature does not yet support the use of the <a4j:repeat> tag for defining dynamic columns. That issue is being addressed as part of RF-7882.

CDK incremental build

With this second 4.3.0 milestone, we’ve carried on with some of the CDK improvements we saw in our first milestone. This time we’ve added support for incremental build with the RichFaces CDK, greatly reducing the time it takes to build RichFaces components, as the CDK now only processes CDK templates and resources that have been touched since the previous build.

Making use of the incremental build for the “RichFaces Components” project reduces the project build time from 2m18s to 1m00s — a 56% decrease in build time. A further reduction in project build time is seen with the proposed new build structure, where we do away with the independent artifacts, and their associated assembly steps.

This is an important achievement, as reducing the turnaround time from IDE to browser improves developer productivity, and let’s RichFaces developer’s more quickly and efficiently deliver bug fixes and new features.

Component Upgrades

A number of libraries within the project have been upgraded in this milestone. This includes upgrading:

In addition, upstream changes in Mojarra required some significant changes to jsf-test, and the jQuery upgrade necessitated upgrading some of the jsf-test libraries as well:

While we currently use jsf-test to mock the faces context and execute our RichFaces unit tests, I’ll take this opportunity to plug the Arquillian extensions Graphene and Warp which the RichFaces Dev and QE teams are developing to allow us to take advantage of the Arquillian revolution, and unit test our components in real containers. Head on over to the Arquillian site to learn more about using these extensions to test your own JSF/RichFaces applications.

Noteworthy fixes

In addition to the above features, RichFaces 4.3.0.M2 delivers a number of additional features and bug fixes, including the fixes released with RichFaces 4.2.3.Final. Some noteworthy fixes include:

RF-12360
The onchange behaviour of the <rich:pickList> has been changed to fire whenever the picked value list changes, rather than waiting until the component loses focus.
RF-12397
A MyFaces profile has been added to the RichFaces showcase build
RF-12457
The <rich:validator> has two new attributes onvalid and oninvalid that can be used to trigger a javascript callback when validation succeeds/fails. Thanks for this addition Bernard!
RF-12492
A visual improvement, the <rich:inputNumberSlider> gets a new handle, in the style of the progress bar.

Moving forward

As per the RichFaces road map, we have one final milestone scheduled for RichFaces 4.3. Work has already begun on RichFaces 4.3.0.M3 after which there will be a CR1 release, followed (hopefully!) by the Final release. Then it’s on to RichFaces 5 where we will implement the new RichFaces build. Tune in to the RichFaces developer forum, where we will soon start the discussion and planning of what will be in RichFaces 5 in addition to this build re-structure.


Tuesday, August 7, 2012

RichFaces 4.3.0.M1 Release Announcement

RichFaces

The first milestone release of RichFaces 4.3 (4.3.0.M1) is now available. This is a significant release, with primary focus on improving the RichFaces Component Development Kit (CDK) – the tool we use to author our JSF components. A second goal of the release was to improve our MyFaces support, which we accomplished by fixing a number of issues, and identifying some further issues to be addressed in a subsequent 4.3 milestone release.

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

CDK Improvements

RichFaces Component Development Kit (CDK) is a heavy-lifter in the RichFaces Framework. The CDK is the tool we use to author our JSF components. Improvements we make to the CDK improve our ability to deliver components, and will reduce our turnaround on delivering new features for developing web applications.

RichFaces developer Paul Dijou has written up a great summary of the recent CDK improvements. For further details on what has changed, you can refer to the list of individual issues addressed. While the bulk of CDK changes have landed in M1, we will undoubtedly introduce further improvements throughout the rest of the 4.3 release cycle as we push the boundaries on what’s possible with the CDK in our RichFaces Bootstrap sandbox project.

“Real” Tests

Testing of our components and framework has always been a primary concern of the RichFaces project. All our releases to date have been tested not only with unit tests, but also with a large battery of significant number of functional tests. However, functional tests treat the JSF servlet as a black box – we know what we put it and we can test what comes out. On the other hand, unit tests mock the environment where our implementation runs, hiding any issues that would occur only in a real environment. If you think about it, these tests operate in a blind-folded manner: what’s happening as the container executes our application logic?

To this end, the RichFaces project has co-ordinated with the Arquillian project in the development of a new extension: “Arquillian Warp”. With Warp, we can write tests that assert state simultaneously on both the client and the server. For JSF, this means our tests can assert state at arbitrary points throughout the JSF lifecycle. As you can imagine, this opens up a whole new category of tests we can write, as we can not only assert that our application logic has the desired effect, but also that it executes as we expect.

Warp reuses outstanding Arquillian integration with various containers, which allows us to test the integration of RichFaces with many application servers and servlet containers. Furthermore, Warp leverages the Arquillian Drone extension for running Selenium-based tests. Arquillian’s flexibility together with Drone’s ability to drive both real and mocked browsers (ie. HtmlUnit), allows us to run tests using minimal resources in continuous integration, and we can run those same tests in “real” environments to verify integration with many real containers.

Our integration tests makes heavy use of ShrinkWrap to create micro-deployments allowing us to separate the project into small testable pieces. ShrinkWrap Resolvers provides support for resolving various modules from our multi-module project, while ShrinkWrap Descriptors allows us to programatically describe configuration files (like faces-config.xml and web.xml), property files, and Facelet files – which enable us to write tests once and run them in many different configurations.

So far we’ve used this new capability within the framework to harden our RichFaces Push and Resource Mapping implementation, and we will continue to develop new cross-container integration tests of our components and frameworks to complement our already impressive test suite.

Issue highlights

This milestone release addresses a number of bugs as well as new features. For a full list of issues addressed, be sure to check out the Release Notes. However, there are a couple of issues I would like to call out in this blog.

The rich:jQuery function in EL to call a jQuery object from a JSF id as in:
#{rich:jquery('your-id']}

This is a convenience method introduced as a short-hand for the current:
$('##{rich:clientId('your-id')}')

The RichFaces a4j:push feature now has a max inactive timeout, that specifies the maximum amount of time a session is allowed to be inactive. This is an experimental feature, put in place as a workaround while we resolve the underlying issue RF-12219. Try it out, let us know what you think!

Component Upgrades

The RichFaces project is very much an open source project, and leverages other open source projects wherever possible. In this milestone release, we updated the version dependency of some of our upstream projects. These include:

  • RF-12176 – Upgrade to Atmosphere 1.0.0.beta4
  • RF-12334 – Upgrade Mojarra to 2.1.7
  • RF-12335 – Upgrade MyFaces to 2.1.8
  • RF-12336 – Upgrade jQuery to 1.7.2
  • RF-12371 – Upgrade Maven project dependency to 3.0.4

MyFaces Issues

With this release, we’ve also turned our attention to a number of MyFaces issues that we hadn’t addressed with our recent releases. In order to co-ordinate with the JBoss EAP 6 release, we focused predominantly on Mojarra compatibility. However RichFaces is a container agnostic project, and we’re making a concerted effort to improve our MyFaces compatibility with our 4.3 release.

This effort is being facilitated both by the Arquillian Warp project mentioned above, as well as by the TomEE project. TomEE gives us an excellent pre-bundled/pre-configured Tomcat and MyFaces environment against which we can both develop and debug our components – without requiring us to assemble the required jars, and “roll our own appserver”.

As with our CDK improvements, fixing MyFaces issues will continue throughout the 4.3 release. M1 is just a first step in this direction.

What’s Next?

In a recent RichFaces community meeting, we set some goals for the M2 release of RichFaces 4.3. These goals include:

  • Restructure the build (according to the requirements being collected in our wiki)
  • Proceed with further MyFaces fixes
  • Iteration/repeating issues
  • Critical/Popular bugs

Also, be sure to follow the RichFaces Bootstrap project:

In the RichFaces Bootstrap Sandbox project, we are developing our next-generation component set based on top of the Twitter bootstrap project. RichFaces developer Paul Dijou has an excellent write-up on the latest bootstrap updates. Also, check out JSF+LESS blog by RichFaces developer Lukas Fryc, showcasing the real-time CSS/LESS development going on in our Bootstrap project – JSF component styling at it’s best!