Richfaces vs. IceFaces - Towards The War

Its provocant this title, isn´t it?

Oh thats like a common newspaper (like the SUN or Spiegel) to fetch up more customers on using such headlines.  But hey, my google ranking must rise ;-)

But back to topic: Both Richfaces-Extensions offers more functionality to achieve a better and efficient grade of component-management of relying frontend-logic. Both tries to get rid of additional libraries that must else be used to increase user-expierience.

For instance if we looking through the biggest part of both libraries: extensible AJAX-Support.  Ever developer that has already worked with AJAX, that some things must be considered before business software - B2B as well as B2C - can be extended by this technology.

What should be gettin “AJAXized”? In which grade of detail should be used synchronization of the client side with the backend? Which “exchange-protocol” should be taken between client/server?

Last but not least: Do i even need it? Or should i say this in that form: You Aint gonna need it if you dont know what benefit you expect to get! Just using AJAX to “get on ride” in the current AJAX-Hype is just like to buy stock-shares if the value has been doubled in a few time without any essential informations about the underlying company! Whats the parallism between this comparison?

All gets return to its base-value and the regarding “stimula” when we see what efford we expect to obtain if we looking forward in a long-term manner!

But what if you want to use AJAX to achieve an really and essentially benefit from it? Well you bothering yourself with this struggling things descriped above - until a few months.

IceFaces as well as Richfaces introduces a new way of handling AJAX-functionalitiy within a side. In most cases you dont even know that you “programming in ajax mode” but more in JSF-style. You just using tags just like before with all of that things we have to add: Backing Beans, Managed Beans, Navigation Rules, Components and so on. Alls seems to be the same.

What we have: We´ve got a tree, some input fields with an result page that calculates some things based on these fields and a “next” button.

But hey, looking forward to the upfront of your browser and see what appears in Icefaces: All calls are “AJAXized”. And when i said all, its meant to be all of it. Even though we using MyFaces, if we got a root-tag inherited from Icefaces, all commands are AJAXized. Thats a strange thing.

All Or Nothing Its Just Like To Get On The Share Value With ALL THE MONEY To A Company With No Expecting Future! What a Hell-Ride.

What makes Richfaces? As soon as we open the Browser we dont see any Ajax. Oh lol. Wht means “see”? Do we “see ajax” is just like “do we see the black hole”? Richfaces drives another approach to achieve the !same! functionality like Richfaces on using a more expliciticaly decleration “Ajaxized”-Components. Therefore you can use the Tag-Library commonly called”a4j” that introduces components to “invalidate  areas”on client side and harnessing whole component-suites between client and server-site. For instance, if you have a tree that display a menu-structure you can deceide whether the tree gets fully transfered to client side and builded up or partly transfered on using AJAX. Furthermore its possible to say that all request will sent to the server - a fully page reload. Thats a choice of three ways. HOLD, SELL OR BUY. Thats what we want!

Next impressive thing is that we can decide fine-grained AJAX-calls on every component of the client side just on adding an a4j component that triggers on particular events on particular elements like an inputArea (e.g. onclick). Thus, we can sent the current value of this field to the server and synchronously to this we can say that “when its sent to server, rerender a component X that displays the newly added value”. Thats why i love Richfaces!

The next cool thing is, that we can declare an area in which we want to use AJAX. For instance this is usefull on using a wizard. Therefore the actions will be triggered not through “normaly h:commandButtons” rather on using a4j:commandButtons that just doing the “same” thing.  The Scope of the declared DOM-Area will be rerendered on processing such an action. Its so easy, you wont believe it, dont you?

The next adorable technique is very hot. You know the problems if you want to  use wizards or formulars that enters multiple sites? You have to manage beans state as we have such a wizard managed mostly with a session scoped bean. If you want to reuse the wizard you must reinitialize the session. But this brings some side-effects in the round that we doesnt expect at development time.

Richfaces tries to solve this BIG issue by introducing the tag “keepAlive”. All pages that belongs to a Wizard must have such a tag with an attribute being labeled “beanName” with the appropriated value-managed-bean. This managed bean stores all the values of the wizard. You can now set down the scope to request of this bean as the bean have not such a lifetime like a session. What means this? If you visit a site doesnt containt such a tag the bean will be purged from the “Special-Richfaces-Session” and all informations gets lost. Thats what we want. In combination with an a4j:include we have found a realy good solution to get rid of that badly managed session scoped beans.

And to all of this examples i just have to say: It works just from the beginning.

I prefere until now in every web-project that must handle  some ordinary datatypes and progresses Richfaces to improve agility on development and to enhance the User-Expierience.

June 3, 2009 | Filed Under Uncategorized

 

Comments

3 Responses to “Richfaces vs. IceFaces - Towards The War”

  1. rainwebs on December 11th, 2009 8:03 am

    Yes, this article ranks high in Google, but the content is questionable. Seems you don\’t know much about ICEfaces. The best thing about ICEfaces is that it hides AJAX completely and the developer don\’t have to think about how to care for the partial updates in a page using special AJAX tags. My experience shows me that this let the developer concentrate on what is important: the presentation of content.

    Packt Publishing has two new books for those who want to have a deeper look:

    http://www.packtpub.com/icefaces-1-8-next-generation-enterprise-web-development/book

    http://www.packtpub.com/jboss-richfaces-3-3/book

  2. admin on December 11th, 2009 1:26 pm

    Thank you for your comment ;-)

    My OpenSource Project LogicalDOC(www.logicaldoc.com) a well performing DMS uses this technique at this moment. So i can decide for my self which technology is the best one to build up complex sites. So my mention is even today not better as i wrote this post according to IceFaces. The components of IceFaces are only “AjaxAble” and thats the point i miss something like “yes it can ajaxable but must not” so i can use a full page reload. Correct me if am i completaly wrong but this doesnt work at all. If you dont want to get use of Ajax and Icefaces you´ll use MyFaces-Implemenation and thats the way i dont want to go. Richfaces is therefore better suited.

  3. Arshad on March 25th, 2010 2:56 pm

    But RichFaces does not perform well with websphere??? For me, that was the main reason to select IceFaces instead RichFaces.

Leave a Reply




Security Code: