I am a core developer for JBoss, and the RichFaces project lead. I work with the Seam, and JBoss Tattletale projects as well. I also coauthored the DZone RichFaces Reference Card. I have been designing and developing enterprise applications for over ten years specializing in web tier frameworks, UI design, and integration.
| Recent Entries |
|
26. Feb 2010
|
|
|
17. Feb 2010
|
|
|
22. Dec 2009
|
|
|
16. Dec 2009
|
|
|
22. Nov 2009
|
|
|
06. Nov 2009
|
|
|
14. Oct 2009
|
|
|
05. Oct 2009
|
|
|
31. Aug 2009
|
|
|
26. Aug 2009
|
|
|
11. Aug 2009
|
|
|
08. Jul 2009
|
|
|
01. Jun 2009
|
|
|
18. May 2009
|
|
|
12. May 2009
|
Now that RichFaces 3.3.3 is nearing its final release I wanted to take some time and discuss our plans for RichFaces and JSF 2.0 support in more detail.
RichFaces 3.3.3+
The goal of JSF 2.0 support in the 3.3.3 release is to run your existing RichFaces 3.3.X applications in a JSF 2.0/EE6 environment with little or no changes. This is an important migration step for any large application, and infrastructure.
We have always meant the 3.3.3 release to be a stepping stone for JSF 2 support. We needed to make a trade off between retro-fitting 3.3.X completely for JSF 2.0 ( a major undertaking ), or have limited JSF 2.0 support in 3.3.X and push forward with RichFaces 4.0 where we can really get the most out of JSF 2.0. This is one of the reasons that we are working so hard to get RichFaces 4.0 out.
In addition to the information in our release announcements ( 3.3.3.BETA1 and 3.3.3.CR1 ) and our wiki page Richfaces 3.3.3 and JSF 2.0, a few people have also posted blogs and articles that I think explain the plans for RichFaces support of JSF 2.0 well. DZone posted RichFaces 3.3.3 Begins Support for JSF 2.0 and Max Katz has posted RichFaces 3.3.3 RC1 and JSF 2.
RichFaces 4.0.0
RichFaces 4.0 is where we can really innovate and extend features to get the most out of JSF 2.0. RichFaces did this for JSF 1.2 and we plan to push the specification to the limits, and prototype the future of JSF!
This is going to include:
- New Custom behaviors
- Dynamic resource extensions
- Simplified component development kit (CDK)
- Customizable request queues
- Updated skinning
- Consolidated component set ( with all functionality you expect )
- Performance tuning and review
- Semantic HTML markup changes to make styling easier
- Interoperability with other component libraries
- Module build system for easy contributions
Plus, all the flexibility and stability needed for large scale development. This does mean that taking advantage of some JSF 2.0 features with RichFaces will need to wait for 4.0. The good news is that we are well on our way to our next 4.0 release, and we will have several time-boxed milestone releases to jump start your development.
We are also going to have detailed migration instructions, scripts, examples and a migration bridge to assist users in moving their existing applications to RichFaces 4.0. The details of this are not completely worked out yet, but our goal is make it as easy as possible for users of 3.3.X to migration to 4.0.
I would like to encourage anyone with an opinion or an idea to contribute to the process. Take a look at our releases, post to our forums, check out our meetings and get involved!
[Project Page] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]
The RichFaces team is another step closer to releasing the final 3.3.3 release! Today we are pleased to announce that RichFaces 3.3.3.CR1 is up and ready to try! This is most likely the last release before the final 3.3.3 release, which means it is also your last chance to help us help you :-)
Give this release a run-through and let us know if you have any issues. You can download the bits from the milestone download page or if you are using maven, you can update your dependencies following the RichFaces Maven wiki page.
The 3.3.3 release is a special one for RichFaces. Not only because it adds a great amount of stability, but also brings JSF 2.0 support to the 3.3.X branch. With this release you will be able to run your existing RichFaces applications with JSF 2.0. This is an important step in migrating your existing applications to JSF 2.0. If you plan on running this release on top of JSF 2.0 make sure to checkout RichFaces 3.3.3 and JSF 2.0 wiki page for all the details.
We've tackled quite a few issues, and have stabilized much of the JSF 2.0 support. You can check out the full list of jira issues resolved in the Release Notes for 3.3.3.CR1.
As always please let us know if you have any comments or feedback, and especially if you find any issues.
[Project Pages] [Milestone Downloads] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]
The RichFaces team is pleased to announce that the first milestone of RichFaces 3.3.3 has been released! You can download the bits from the milestone download page or if you are using maven, you can update your dependencies following the RichFaces Maven wiki page.
The 3.3.3 release is a special one for RichFaces because it brings JSF 2.0 support to the 3.3.X branch. With this release you will be able to run your existing RichFaces applications with JSF 2.0. This is an important step in migrating your existing applications to JSF 2.0.
When you innovate on top of a standard (like JSF 1.2), the way RichFaces 3.X did, there are bound to be a few issues when the underlying standard has a major revision as it did with JSF 2.0. While the 3.3.3 release will let you run your applications with JSF 2.0 you'll still need to wait for RichFaces 4.0 for complete JSF 2.0 integration, development, and extensions. There are a couple of known issues, and limitations that you should be aware of, and they can be reviewed at our wiki page : RichFaces 3.3.3 and JSF 2.0. We'll do what we can in the remaining 3.3.3 milestone release to address these, but there are a few items that will need to wait for 4.0.
We wanted to keep this a small and focused release, but this was more than just a release for adding JSF 2.0 support. There were a few stabilization issues we wanted to get in, some other issues brought up by our community. You can check out the full list in the release notes for 3.3.3.BETA1.
We would like to ask our community to give 3.3.3.BETA1 a shot with JSF 2.0 and let us know if you find any issues. We'll be following up this release with either a BETA2 or a CR1 release depending on number of issues found, and complexity of the fixes.
[Milestone Downloads [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]
I wanted to follow up all the great content from Dan Allen on JSFSummit with some of my own, but from a component libraries point of view. One of the really nice things about speaking at a conference like JSFSummit is that you know the attendees are going to be knowledgeable and are likely already using JSF. This meant that speakers could really talk about the details of their topics. For example my talk on RichFace Component Toolbox was able to show users some of the advanced components and features of RichFaces including code examples and a demo (cruel demo gods aside). Something else that JSFSummit and NFJS get right is the length of the sessions, with 90 minutes we could really cover a lot.
Component Libraries Working For You
There was a very strong showing at JSFSummit, and this included the leads from several of the top JSF component libraries. There was Andy Schwartz from ADF Faces, Ted Goddard from ICEFaces, Cagatay Civici from PrimeFaces, and Me representing RichFaces All represented in this rare picture!. You might think that because technically we all have competing projects that this could be testy. I'm very happy to say that is not the case.
All of us, and the rest of the JSR-314 (JSF 2.0 ) expert group had many productive and enlightening discussions. Some of these were late night at the previously mentioned Thirsty Fish at the conference hotel, other were at lunch, in meeting rooms, or even during some of the talks. As Dan said there was no barrier between speakers and attendees and many times we would attend each others talks. This would sometimes spark conversations that started to sound more like a expert group meeting than a presentation. This would usually involve how to work XYZ feature or behavior into the next version of the spec. The great thing about this was that everyone participated, and voiced their opinions.
One of the large discussions involving the various component libraries involved proving one of the tenants and goals of JSF 2.0. That was interoperability, between component libraries so that developers could combine component libraries when ever needed. I am very keen on this topic, and pushed for the different libraries to collaborate on a combined example application. Perhaps we pull a data table from RichFaces, a tree from IceFaces, a menu from ADF, and a collapsing panel from PrimeFaces. This type of application would really do several things. For one it would provide proof and an example to developers that JSF 2.0 component libraries really can work together. For another it will help us all to shake out the lumps and issues developers will run into with the specification.
This second point should not be underestimated. RichFaces in its development of 4.0 has already found some items that need to be worked out
. These items represent areas of implementation that could cause component libraries to not function together, or could also point out areas in the spec that need more definition. To see a listing of some of these items check out our wiki page. I'll give you an example of one of these issues just so you can get a taste:
JSF 2.0 now has build in Ajax support that is supposed to act as a core Ajax bridge that component libraries are supposed to use. This implementation has a very simple queue associated with it. RichFaces has its own advanced queue functionality from 3.3.X that we want to bring forward to RichFaces 4.0. How do we do this without overwriting the core queue, and stepping on other component libraries toes? A few options have been discussed such as allowing developers to choose a single queue implementation that follows a defined contract so that users can switch implementations as they wish. This would be similar to JSF 1.2 where you could plug in your own view handler, a.k.a. Facelets. Another option that was discussed was to have one core implementation, but when it was a requests turn in the queue it would have full control of its behavior.
Needless to say this was not completely resolved, but gives you a taste of the efforts that will be required to make this all meld. As I said above though, what struck me was the willingness of everyone from component libraries leads, EG members, and Jim Driscoll from the RI team to work together on a solution. In the end this is going to result in a better JSF, and component libraries to go with it
Migration Strategies Were Key
Obviously one of the hot topics was JSF 2.0 support, and more specifically how users can migrate from earlier versions to new versions. This came up at literally every talk that I either gave or went to that discussed JSF 2. Users need a solid path for migration in order to leverage their efforts from the past, while moving forward with the technology. There was even a talk dedicated to migration that Kito Mann gave called Upgrading to JSF 2.
Something that surprised some developers was that although JSF 2.0 is backwards compatible, most of the component libraries could not support JSF 2.0 without some modifications. For RichFaces this is because in order to accomplish some of advanced features with JSF 1.2 we needed to interact with some of the core APIs and internals of JSF. This meant that when JSF 2.0 came along and some of those APIs changed it caused problems. The RichFaces team has been working on a solution to this, and migration strategy for our users.
We are current developing the RichFaces 3.3.3 release which will bring JSF 2.0 compatibly to the 3.3.X release branch. We should be releasing a BETA of this release very soon, and hope to have a final release of this by early next year. With this release users can begin to migrate their applications to JSF 2.0 containers, and environments. Update their own code and begin playing with JSF 2.0. It is important to note that this release is more about compatibility. You'll be able to run your existing applications with JSF 2.0, but the release will not take advantage of JSF 2.0 new features and abilities. This will need to wait for RichFaces 4.0.
RichFaces 4.0 is in parallel development, and we have already had a 4.0.0.ALPHA1 Release. This is the release that will really leverage and push the functionality of JSF 2.0. This will include new behaviors, events, and components, as well as an easy to use Component Development Kit. We hope to continue to push the bounds of the standard and begin prototyping the features that someday will be standardized in another version of JSF. We are currently planning to release 4.0.0 in early summer, but will have lots of interim releases between now and then.
So you might be asking yourself, how do I upgrade from RichFaces 3.3.3 to 4.0.0? We are working on the details of that, but rest assured we'll make it as easy as possible. This will certainly include a migration guide with step by step instructions. We'll likely also have a compatibility bridge of some type that will make migration even easier.
Feeling Good
I left JSFSummit feeling very good about a great many things. For one thing Orlando is a nice place to visit in December when you live in New York. More importantly I left feeling very positive about the JSF technology and community. I think JSF 2.0 is a great release that combined with component libraries like RichFaces, and other features in EE6 like CDI and Bean Validation really make an application stack that is hard to compete with. I'm also very excited about RichFaces future, and the great community and developers that we have.
Thanks to everyone that attended, and all the speakers and expert group members that were there!!
[javaserverfaces.org [RichFaces Project Site] [Downloads] [RichFaces Twitter]
Several of us from JBoss will be presenting at JSFSummit in Orlando Florida between December 1st and 4th. We'll be covering lots of different content from general RichFaces how-to
sessions, advanced component demos, JSFUnit, Seam, CDI, and other JSF related topics.
- RichFaces Component Toolbox: Today and Tomorrow by Jay Balunas
- The Best Kept Secrets of Seam, RichFaces, JSF and Facelets by Jay Balunas
- CDI (JSR-299), Weld and the future of Seam by Dan Allen
- JSF 2: Keeping Progress Coming by Dan Allen and Andy Schwartz
- Seam & RESTeasy: You haven't seen REST yet by Dan Allen and Lincoln Baxter III
- Maturing your application's security with Seam Security by Dan Allen
- Dumping JSF by Stan Silvert
- Holistic testing of JSF applications by Stan Silvert
For all the details, and times check out the JSFSummit Sessions page. We've also updated the RichFaces project calendar page with this info!
Also don't forget to register if you have not already!!
[Project Site] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]
| Showing 1 to 5 of 32 blog entries |
|
|