ZK vs. Ajax JSF Components: Simplicity Matters!

DZone 's Guide to

ZK vs. Ajax JSF Components: Simplicity Matters!

· ·
Free Resource


  1. Abstract
  2. Innovation vs. Refinement
    • ZK - Innovation
    • ICEfaces - Refinement
    • ZK vs. ICEfaces
  3. ZK vs. ICEfaces in Action : Google Maps Locator
    • ZK (1 File, 36 Lines of Code)
    • ICEfaces (3 Files, 223 Lines of Code)
  4. Mobile Solution
    • What about the devices without browsers?
    • ZK on Java Phones
    • ZK on Google Android
  5. Conclusion
    • Ajax Framework or Another JSF Components Set

1. Abstract


From the previous article¡X ZK vs. GWT, the importance and advantages of server centric architecture were discussed and outlined. By server-centric approach, developers simply do the programming on the server side using Java. There will be no replication of business logic on client, no hassles of asynchronous programming, and no hazards of exposing business logic on client.

There are more and more Ajax frameworks adapt this architecture like ZK, Backbase, Richface and so on. In this article, ZK will be compared with one of Ajax JSF components sets-ICEfaces.


2. Innovation vs. Refinement

ZK - Innovation:

ZK is an open-source Ajax framework which enables Java developers to create rich Web applications with little programming. With the server-centric architecture and event-driven model, developing Web applications becomes as intuitive as programming desktops. With 170+ Ajax components and mark-up language, designing rich user interfaces becomes as simple as authoring HTML pages. Without declaring each managebean in configuration, ZK provides more flexiable and dynamic mechanism to achieve data accessing, annotation-databinding and variable-resolver. In recent releases of ZK, developers can even bind Java Bean into an Ajax spreadsheet application. This technical breakthrough will bring a new age to web applications developing.

To Know more how ZK works as a server-centric framework, refer to the following: Also, for migrating page-based JSF to Ajax JSF, ZK offer its own JSF components set. Refer to:

ICEfaces - Refinement:

ICEfaces is a components set for JSF. More than 50 Ajax components for JSF are supported by ICEfaces. As ICESoft mentions in the ICEfaces document, Icefaces framework is only an extension of standard JSF. It is still a traditional page-based architecture. The key difference is that ICEfaces only render the incremental changes in the rendering phrase rather than the standard JSF approach¡Xrender all DOM tree. From this point, ICEfaces's Ajax Bridge, which is a mechanism to communicate between client and server side will modify the DOM tree in client side asynchronously. As a result, the ICEfaces application still needs going through the standard JSF lifecycle.


3. ZK vs. ICEfaces in Action : Google Maps Locator

In the following section a simple Google Maps Locator application will be implemented by ZK and ICEfaces in order to demonstrate the difference between the frameworks. Assuming that you are coding a Google Maps Locator for a client, the requirements might contain:

  1. An UI with a text input field, a button and a Google map.
  2. When user clicks the button the text in the textbox will be used as a keyword to find the latitude, longitude and description for that location.
  3. Displaying the location on the Google Map and display the description as an Info Window.

Figure.2 - Google Maps Locator

Let us assume you have already implemented a magical Java class which is called "Locator." It will take a string as input and return the required information. The only work left is implementing the UI and data retrieval parts. Let's see code from both frameworks in real action.

ZK (1 File, 36 Lines of Code)


<?xml version="1.0" encoding="utf-8"?>
<script src="http://maps.google.com/maps?file=api&v=2&key=KEY"
import com.macroselfian.gps.Locator;
public void locate(){
String location = tb.getValue();
double[] pos = Locator.locate(location);
mymap.panTo(pos[0], pos[1]);
<div align="center">
<separator spacing="50px" />
<label value="Macroselfian Google Map Locator"/>
<hbox width="600px">
<textbox width="550px" id="tb"/>
<button width="50px" onClick="locate();" label="Search"/>
<gmaps id="mymap" zoom="16" ...>
<ginfo id="ginfo"/>

Adapting Direct RIA architecture, ZK is 100% event-driven model which decouples user interface from business logic. From code above, 3 advantages of Direct RIA architecture can be found.

First, developers directly access data without extra backing beans; this offers a more intuitive approach than JSF backing beans.

Second, no extra configuration for each component and controller. It gives developers more flexiblity than traditional page-based application.

Last, ZK offers the zscript element which allows developers script in Java directly on the zul file. By scripting in zscript, developrs directly manipulate components, EJB beans, Java Beans, or even the variables from JRuby interpreter, the interaction within components becomes a straight-forward task.

Icefaces (3 Files, 223 Lines of Code)

Jspx Page:

  • gmap.jspx

Java Bean:

  • LocatorBean.java

JSF Config File:

  • faces-config.xml

Code Snippet:


<f:view xmlns:h="http://java.sun.com/jsf/html"
<ice:outputDeclaration doctypeRoot="HTML"
doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN"
doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" />
<meta http-equiv="Content-Type" content="text/html; /> <link href="xmlhttp/css/xp/xp.css" type="text/css" rel="stylesheet">
.iceGmp {


.iceGmpMapTd {
vertical-align: top;

.iceGmpMapTd div.gmap {
width: 800px;
height: 600px;
<ice:outputConnectionStatus />
<ice:inputText value="#{locator.location}" width="200px"
partialSubmit="true" />
<ice:commandButton type="submit" value="Submit" />
<ice:gMap latitude="#{locator.lat}" longitude="#{locator.lng}"
<ice:gMapControl id="largectrl" name="GLargeMapControl" />
<ice:gMapControl id="scalectrl" name="GScaleControl" />
<ice:gMapControl id="typectrl" name="GMapTypeControl" />
<ice:gMapMarker id="gmarker">
<ice:gMapLatLng id="glatlng" latitude="#{locator.latMark}"
longitude="#{locator.lngMark}" />


package com.macroselfian.gps;

public class LocatorBean {
Locator _locator;
String _lng ="0.0";
String _lat ="0.0";
String _lngMark ="0.0";
String _latMark ="0.0";
String _title ="";
String _info ="";

public String getLocation() {
return _locator.getKey();

public void setLocation(String location) {
_locator = new Locator(location);
_lng = _locator.getLng()+"";
_lat = _locator.getLat()+"";
_lngMark = _locator.getLng()+"";
_latMark = _locator.getLat()+"";
_title = _locator.getTitle();
_info = _locator.getInfo();

public LocatorBean() {

public String getLatMark(){
return _latMark;

public void setLatMark(String lat){
_latMark = lat;

public String getLngMark(){
return _lngMark;

public void setLngMark(String lng){
_lngMark = lng;

public String getLat(){
return _lat;

public void setLat(String lat){
_lat = lat;

public String getLng(){
return _lng;

public void setLng(String lng){
_lng = lng;
public String getTitle() {
return _title;

public void setTitle(String title){
_title = title;

public String getInfo() {
return _info;

public void setInfo(String info){
_info = info;



<?xml version="1.0"?>

<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
<!-- -->


Icefaces inherits burdens from traditional page-based JSF. As a reault, ICEfaces developers use JSF's backing bean concept, and the 6 phases lifecycle. But, as mentioned above, developers need to be familiar with the controversial JSF lifecycle and backing bean concept in order to painlessly deal with ICEfaces. From the above example, an additional wrapper bean class is needed for wrapping the magical locator class. At first, it is confusing for a developer who is new at JSF. For example, should I add an additional pair of coordinates to wrapper for saving the latitude and longitude of current center?

From above, one can easily tell that ICEfaces only solves the "richness" issues of JSF. It is still necessary for developers to understand the 99% of JSF concept. Does it do any good to a web application developer who wants a framework is easy to learn and fast develop? I don't think so. In my personal experience, if you are not familiar with JSF or the legacy application is not designed with JSF JavaBean concept, ICEfaces won't be a painkiller; it will be another trouble maker.


4. Mobile Solution

What about the devices without browsers?

Many Ajax JSF frameworks support mobile device. But, the problem is that they are limited by browswers in smart phones. What about 1.8 billion Java phones which do not come with such resources (computing power, memory, browser, etc.) that iPhone provides? The server-centric/thin-client approach by ZK brings benefits to those resource constrained devices. Your client devices will not be limited to robust ones with browser. With ZK, you can run your Web applications anywhere without device resource restriction.


ZK on Java Phones

Figure 3 - ZK on Java Phone

More articles about ZK Mobile



ZK on Google Adroid

Figure 4 - ZK on Android

More articles on ZK Android



5. Conclusion

Simplicity Matters!

Comparing to ZK, ICEfaces is more like a JSF components set than an Ajax framework. This tells that Ajax JSF componenets such as ICEfaces doesn't get rid of the JSF complicated lifecycle and configuration. For those who already are JSF experts, Ajax JSF solutions like Richfaces and ICEfaces might be painkiller for adding Ajax to projects. But, for whose get tired of JSF and look for a new Ajax solution suffer from the difficulty of customizing component and its complicated configuration.

"Comparing to JSF, ZK is on a whole new level."
-Daniel Seiler, COO of processwide


From above, one can conclude that comparing to JSF, ZK is much easier to learn by its intuitive programming style. I believe in that JSF is a well-defined standard. But, it is designed for the time when people design application by "page-based" pattern. When Ajax emerges and becomes the must-have, probably it is time to consider about the next generation web application frameworks. Ajax is simple, but people insist making it complicated.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}