![primeface vs icefaces vs richfaces primeface vs icefaces vs richfaces](http://cdn-ak.f.st-hatena.com/images/fotolife/k/kikutaro777/20130505/20130505220841.jpg)
RichFaces has its own advanced queue functionality from 3.3.X that we want to bring forward to RichFaces 4.0. This implementation has a very simple queue associated with it. 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. I'll give you an example of one of these issues just so you can get a taste: To see a listing of some of these items check out our wiki page. 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. RichFaces in its development of 4.0 has already found some items that need to be worked out. This second point should not be underestimated. For another it will help us all to shake out the lumps and issues developers will run into with the specification. For one it would provide proof and an example to developers that JSF 2.0 component libraries really can work together. This type of application would really do several things. Perhaps we pull a data table from RichFaces, a tree from IceFaces, a menu from ADF, and a collapsing panel from PrimeFaces. I am very keen on this topic, and pushed for the different libraries to collaborate on a combined example application. That was interoperability, between component libraries so that developers could combine component libraries when ever needed. One of the large discussions involving the various component libraries involved proving one of the tenants and goals of JSF 2.0. The great thing about this was that everyone participated, and voiced their opinions.
Primeface vs icefaces vs richfaces how to#
This would usually involve how to work XYZ feature or behavior into the next version of the spec. This would sometimes spark conversations that started to sound more like a expert group meeting than a presentation. As Dan said there was no barrier between speakers and attendees and many times we would attend each others talks. 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. I'm very happy to say that is not the case.Īll of us, and the rest of the JSR-314 (JSF 2.0 ) expert group had many productive and enlightening discussions.
![primeface vs icefaces vs richfaces primeface vs icefaces vs richfaces](https://image.slidesharecdn.com/jsf2primefacesrichfacesicefaces-100826052650-phpapp02/95/jsf2-c-primefaces-richfaces-e-icefaces-9-728.jpg)
![primeface vs icefaces vs richfaces primeface vs icefaces vs richfaces](http://www.opendart.com/uploads/PrimeFaces.png)
You might think that because technically we all have competing projects that this could be testy. 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!.
![primeface vs icefaces vs richfaces primeface vs icefaces vs richfaces](https://i1.wp.com/www.primefaces.org/wp-content/uploads/2016/08/9908OS.png)
There was a very strong showing at JSFSummit, and this included the leads from several of the top JSF component libraries. Something else that JSFSummit and NFJS get right is the length of the sessions, with 90 minutes we could really cover a lot.
Primeface vs icefaces vs richfaces code#
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). This meant that speakers could really talk about the details of their topics. 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. 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.