I have to decide between using ICEFaces or RichFaces UI components and I am not sure yet which one should I use, so I have the following questions:

- Do they cause problem when they are used with tomahawk components?
- How well do they integrate with Eclipse 3.3 and Red Hat Developer Studio?

I am more inclined to ICEFaces since the documentation seems to be better than RichFaces and they seem to have more components, but Red Hat Developer Studio will have better support for RichFaces than ICEFaces for obvious reasons.

Also, I am using MyFaces 1.1.1, I read that MyFaces 1.2 has just come out some weeks ago, but I suppose it still has some bugs so it may be prudent to wait. Nevertheless, it makes me wonder if I should change to RI 1.2, which advantages does it has over MyFaces? Does the tomahawk components work ok with it?

Thanks

 

 

Apache tomahawk is 100% compatible with JSF RI 1.2.

 

 

That's good to know, which advantages does JSF RI 1.2 has over MyFaces 1.1.1 or MyFaces 1.2 for that matter.

 

 

The Sun RI has been released for much longer thus would likely be more tested and hardened than MyFaces 1.2.

As far as the Sun RI vs MyFaces 1.1.x, well there is the JSF 1.2 vs 1.1 thing to consider.

 

 

I have just counted the number of components that will be included into RichFaces 3.1.0 release. The total is 58 components. I did not count dropDownMenu, menuItem, menuGroup, menuSeperator as four components because is one feature for end developer.

The counter for IceFaces ends on 27 components.

So, speaking about the numbers, you was not quite correct.

 

 

Well according to http://www.icefaces.org/main/product/whyicefaces.iface they said that they have 50+ components.

Where is the richfaces component count?

 

 

I recently did some thorough comparisons of RichFaces and IceFaces. The two are similar but there are a number of differences. Overall I like IceFaces better but ended up using RichFaces due to a number of serious design issues with IceFaces which were show stoppers for us.

1) RichFaces provides concept of eventsQueue to prevent too many AJAX requests getting sent. IceFaces has no equivalent.

2) RichFaces modal panels can be displayed using Javascript - haven't figured out how to do this easily using IceFaces.

One major drawbacks of the RichFaces library is the lack of a pop-up date calendar component for date input.

 

 

There are 2 aspects to consider when choosing between ICEfaces and A4J/RichFaces. There is the component suite, and the underlying framework. In both cases you can expect the component suites to evolve and the numbers and sophistication of components to increase.

I think the major differences come in the framework. The major advantages to the ICEfaces framework over A4J are:

1) Page-level Ajax: With ICEfaces the framework figures out how to make the page updates. With A4J the developer needs to wire together the part of the page that might effect each other. This can be a tedious exercise and impacts the separation of roles between the developer and designer. With ICEfaces the page update mechanism is completely transparent to the developer and the designer. They can focus on application features.

2) Ajax Push - The ability to push presentation changes to the client in an asynchronous fashion is a fundamental capability of the ICEfaces framework and always has been. Most other frameworks are playing catchup in this regard. A4J does not support Ajax Push as of yet.

I believe these fundamental differences outweigh the overall component count available at any instant in time. But of course components are important so we are always pushing the component suite forward. Additionally, ICEfaces will soon be introducing new component rendering APIs that greatly simplify component development, and we will be fostering component development within the community. You can definitely expect the ICEfaces component suite to blossom with new components over time - and page-level update and AJAX push will always be there as it is part of the framework, so all components benefit.

Also, the ICEfaces technology is not shackled to JBoss technology, but is well-integrated with it. Not only does ICEfaces have full integration with the JBoss application server, and important middleware like JBoss Seam, but it is integrated with other technologies like Spring and Liferay . It is also integrated with the whole spectrum of IDEs, so you can work within the development environment that you are comfortable with.

So count components if you like, but consider the underlying power of the framework first. I think ICEfaces will win every time.

Steve

 

 

We chose ICEfaces in our enterprise project. It is really excellent. ICEfaces Spring Hibernate.

 

 

Wow. I missed something. The thread is still alive.

Shortly, rich:push was introduced as a part of Richfaces about two months ago.

I did not count renderer for h:inputText. Renderer is a renderer. Component is Component. h:inputText belong to the standard and comes from the JSF implementation

menu, menuItem, menuGroup, menuSeparator are four different tags, but it is only one component from the end developer point of view. So, I counted it as one component, not four.

 

 

I've been using Dynamic Faces? Where does it compare to these two?

 

 

That god bless you : http://www.jsfmatrix.net/

 

 

Our team has done several demos as well as some research on IceFaces as well as RichFaces.

Here is what we find out:

o- The only advantage that we saw with IceFaces is of maturity in the concept of Ajax push or Direct to DOM rendering.

o- If you are thinking about the terms like Reliability, Support, Free license with most most advance development environment, IT IS RichFaces Ajax4JSF development environment.

o- Ajax4JSF (supported with RichFaces) will have to mature with its approach of A4J: poll and A4J: push (as commented by Sergey.Smirnov) approach, which can still grow with new releases.

o- About Development Environment
IceFaces is still facing troubles with Eclipse Jee Europa with web tools.
Some of the problems are:
1. Creation of New projects gets stuck.
2. It doesn't support JSF 1.2 and error messages like "IceFaces 3.0.0 doesn't support JSF 1.2".

We will never wish to work like that.

RichFaces on other hand beautifully fits into the same environment and also supports A4J.


--Development Environment Tip: Use Eclipse 3.3.1 Europe with WTP 2.0.1 support JBossTools-2.0.0 Plugin (Inbuilt world class Exadel Studio) OR You can also get the latest Red Hat Developer Studio for even better Dev environment.

o- Last but not the least, think about a situation where none of the existing components provided by IceFaces or RichFaces are of any use. You will need a life saver.
RichFaces is the only one (according to my knowledge; can suggest) using which you can write your own custom rich components with built-in AJAX support.

Can any one tell me any alternative for the same? I didn?t find any.

Last thought: Ajax push provided by IceFaces has advantage of DOM rendering but what we have found out is that it is a memory kill and damn slow when comes to real world requirements and deployments. What is IceFaces doing for that?

All of the above comments are based on our team's experience with IceFaces and RichFaces in last few months.
We think JBoss support and perfect thought process can make RichFaces + A4J much more successful than IceFaces.


And ya...link (http://www.jsfmatrix.net/) provided by kokorico is not up-to-date and RichFaces supports much more than mentioned there

Edited by: KURAL on Jan 18, 2008 6:42 AM

 

 

Another reason to use RichFaces is here.

If you wish to test your RichFaces and Ajax4JSF applications.

JSFUnit includes support for RichFaces and Ajax4jsf components. Beta 1 version of this framework was released last month and the second Beta Version release is scheduled for the end of next month.

here is the link for the same

http://labs.jboss.com/jsfunit/

 

 

I have also evaluated both in octobre for a week for our project, i tried with both at real application, i tried especially the more complicated Trees. IceFacec had some strange behavours like simple javascript alert() not worked which was astonishement, second it losed sometimes all stylesheets when going to another page, third when exception/session timeout happended the framework shows up a message and i had to close all browser windows before i could reenter the application... The framework seems powerfull but somehow those experiences made me afraid whats all going up, too much blackbox. - We use now for 3 month Richfaces with no problem; where the Components not do what i want i could solve it with adding some javascript with no problem/any strange behavors. I just use components where needed or add ajax where really needed. Each Version brings some fixes. So Recommend Richfaces.