The answer is simple. Never. The purpose of this post is to explore what ICEfaces really is, and why it’s counterproductive.
What is ICEfaces?
ICEfaces is a really cool idea, honestly. It’s a framework that extends the standard JSF framework, and was intended to simplify the programmer’s workload by removing Javascript from the equation. In otherwords, ICEfaces handles all of the Javascript and Ajax for you automatically. ICEfaces differs from the JSF Framework in only one respect. The JSF Framework forces an entire webpage to refresh with each action, while ICEfaces utilizes Ajax to incrementally change portions of a webpage dynamically. This is definitely a huge advantage over JSF. The problem with ICEfaces, however, is that its concept is too idealistic to actually work in the real world.
What’s the problem with ICEfaces?
The problem with ICEfaces, like any other framework similar to it, is simple. If your web application happens to use every feature that ICEfaces provides, with no variation, then sure, ICEfaces would probably be fine for you. The problem however, is that if you want to create specific functionality or behaviors that ICEfaces doesn’t offer, you’re forced to endure the painful task of integrating your custom functionality with ICEfaces.
ICEfaces isn’t magic
A lot of people seem to think that ICEfaces is a completely new technology that’s revolutionizing the web. Unfortunately, it’s simply a collection of custom Java tag libraries that utilize Ajax and Javascript. If you have a decent team of web developers, they should be able to construct Ajax calls themselves with Javascript quite easily. In this respect, it makes more sense to go ahead and build your applications from scratch using Javascript and Ajax so that you have full control over your own framework. In my experience, developers spend much more time trying to make custom features compatible with ICEfaces than if they had just not used the framework in the first place.