Liferay, jQuery, and ICEfaces

Our recent announcement about jQuery caused a lot of confusion among the JSF camp because it seemed to contradict another announcement we made a few months ago concerning ICEfaces. So this blog is meant to clear that up.

ICEfaces serves the need of abstracting Javascript from Java developers. It does that very well. It allows Java developers to develop using JSF to implement portlets with a rich UI. The very benefit of ICEfaces however, is also its drawback. It requires developers to use JSF.

jQuery on the other hand, is a light weight Javascript framework that enables PHP and Javascript developers (and Java developers who don't want to use JSF) to quickly develop without having to learn a heavier Java framework.

At Liferay, we don't care what you write your portlets in. Often, our enterprise clients mix and match technologies to get the job done. That's why we focus on enabling developers to deploy portlets, often deployed in one page, to be written in languages and frameworks like Struts, ICEfaces, PHP, or even Ruby.

ICEfaces' current implementation uses a Javascript library called Prototype which pollutes the DOM and does not coexist well with other Javascript libraries. That means, if we built our internal core portlets using ICEfaces, it could potentially break portlets that other people have written. With that said, we have decided to build all of our internal portlets using jQuery.

In the plugins repository, however, our non core portlets do leverage a variety of JSF technologies, of which our favorite has been ICEfaces because of the push behind both Liferay's community and ICEfaces' community to make sure integration works.

Hope that clears everything up.

[Nate Cavanaugh]

Heya Brian,
I'd like to clarify what I believe you meant.

ICEfaces itself doesn't pollute the DOM. The culprit here isn't ICEfaces, but rather Prototype and Scriptaculous, which powers their Javascript implementation.

Prototype and Scriptaculous are notorious for not existing well with other Javascript libraries, and was never designed to exist in the context of a portal.

Prototype pollutes not only the global namespace, by declaring common global variables that other people will use (Such as Ajax, Hash, and the infamous $ functions), but also by modifying the native object prototypes.

Here is a good example:

Let's say someone deploys one ICEfaces portlet that uses the latest version of Prototype (1.6.) and they also include a portlet running Prototype version 1.4 or 1.5, which is still commonly used in many production systems, now either the ICEfaces portlet will break, or the other portlet will.

ICEfaces is a totally separate product from Prototype/Scriptaculous, and Neil Griifin, Paul Bakaus and I have talked to Ted Goddard, Mircea Toma and Deryk Sinott about migrating off of it.

There are currently a number of widely supported Javascript libraries that are just as powerful as Prototype/Scriptaculous, and we're working really hard to get jQuery UI to be their first choice, but they're not locked into using anything we push.

In the end, I think their goals are good, and the ability for Java developers to quickly make nice looking UI's is one that I think they'll have a lot of success with.

Hopefully that might clear up any confusion that might arise from the blog post

[Brian Chan]

Btw, when I wrote "drawback", my main focus was from the perspective of those who wanted to write portlets in PHP or other languages.

I in no way meant that JSF or ICEfaces was a drawback. In fact, many of our enterprise clients use JSF and specifically ICEfaces. And, we've only seen adoption skyrocket in the past year as we've worked more closely with ICEsoft's great team.

[Mike A Lawrence]

Brian,

We choose to develop our Liferay portlets in ICEFaces based on your announcement.
So far we've been successful and found it to work well as long as you only place
one portlet on a page (ICEFaces v6.2). This limitation is supposed to be fixed in v7.

Sorry to hear you're moving away from ICEFaces. I do understand your concerns.
If ICEFaces switched their javascript to jQuery would you be using ICEFaces instead
of jQuery?


PS Please tell Caris that Mike and Sandy said hello!

[Brian Chan]

Hey Mike!

Caris says hi too.

We're not moving away from ICEfaces... we have a lot invested in JSF with ICEfaces for our hot deployable portlets. We've also been talking to ICEfaces about how to get their framework to use jQuery instead to get around some of those limitations you just mentioned.