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. 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!. 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.
Lastly, the "automatic AJAX" server-side DOM diff in ICEfaces can create performance issues server-side if your pages get big - most of the time you know what you want to refresh, and explicitly specifying update="id" on a component is more effective.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.
In PrimeFaces, thanks to "widgetVar", you can bind the component to a client-side variable accessible in jQuery and regular DHTML events.įurther, the PrimeFaces components handle many of the common cases with less code for example, a dialog component includes the title bar and the "X" to close, while in ICEfaces you have to roll your own for that (or buy the EE with composite components). In ICEfaces, you need a server-side round trip and a managed bean property + action listener to open a dialog. I've used both ICEfaces and PrimeFaces and prefer PrimeFaces for two main reasons: development efficiency and UI performance/responsiveness.
0 kommentar(er)
