The third milestone release of RichFaces 4.0 is now available!! With this release we have added a few new components, GAE support, and more. As before you can download the distribution at our RichFaces download page. The RichFaces-4.0.0.M3 distribution has everything you need to get started. Check out the readme.txt files for any details, or dependencies. If you are a maven user you can follow the instructions here: How to add RichFaces 4.X to Maven Based Project.
As you may have seen several of the RichFaces team presented and attended JavaOne. During our talks we announced and discussed several items that are starting to emerge in milestone3. There was a lot of interest in the new client side validation support that will bring bean validation all the way to the browser. Imagine the scalability impact if you can avoid server hits for validation! We also discussed support of JSF 2.0 and RichFaces 4.0 on cloud based hosting like GAE. With more to come...
Updates:
- Our new Resource Plugin is done, and enables support for Cloud deployments and serving dynamic resources statically.
- New Components tabPanel, inputNumberSpinner, collapsiblePanel, and progressBar
- Google App Engine (GAE) support via a new gae-archetype, and a gae profile for building the richfaces-showcase.
- Prototype and initial development on Client Side Validation
- Updated richfaces-showcase with new components
- Stabilization work for core, CDK, and migrated code. Automation tests with quint, junit.
The 4.0.0.M3 Release Notes contains all the details, and specific issues. We would be happy if you can give this release a try, and let us know how it goes. The good, the bad, and the bugs….
Next Up Milestone 4
For Milestone 4 we will be working on more components like finalizing client side validation, calendar, tree, fileupload, and more. There are also going to be some updates to our Push components that should be exciting to see. We are looking at a November release for Milestone 4.
If we are missing your favorite component, or if you find an issue please let us know through our forums, or our project jira. You can also see our current plans by following the 4.0.0.Milestone4 project in jira, or dropping by one of our public IRC meetings. See our Project Calendar and the Meeting Information page for more details, agendas, and minutes.
[Project Site] [Downloads] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]
RichFaces 4.0.0.M3 Release Notes:
Known Issues :
Thanks for the tip about MyFaces 2.0.2 issues, as now I won't waste time when errors display.
Tom
I read your post about JavaOne and Richfaces 4.0. I really liked how Richfaces 4.0 will handle form validation (cross-field validation). This kind of validation was a pain for JSF, so, despite some limitations of your approach, it´s functional and easy to use.
I must confess I am very impressed by the diretions that Richfaces is taking, so, it´s worthy waiting.
ps: my fellows didn´t belived when I told then about client-side validation that is based on BeanValidator :)
Hi Flavio,
We appreciate the words!!
You can track client side validation in jira here RF-8742
It is planned for Milestone 4, although complete functionality might be during Milestone 5. We are excited about it as well. Any feedback or ideas is aways welcome!
Thanks, Jay
What version of MyFaces is a Good Fit for testing Milestone3?
Thanks Jay.
Appreciate the hard work and look forward to upgrading my application with the latest Richfaces (I bypassed migrating to RichFaces 3.3.3 hoping to straight to 4).
I hope RichFaces team can work with OpenFaces together and avoiding duplicated work...
OpenFaces provieds some sex features which are not implemented in RichFaces, such as.
We are using MyFaces 2.0.2, but as I said there are some integration issues that we are working out. Feel free to try it out though, and let us know what you find. We're hoping to focus on MyFaces integration at the end of M4 development ( next week ).
I'm not sure we'll be able to avoid duplicating component functionality. To be honest - I'm not even sure it makes sense to try. Giving developers options and differing implementations is a positive thing.
However we would certainly be interested in working with component libraries on interoperability so that developers can use components from different libraries together.