ZK vs. Ajax JSF Components: Simplicity Matters!

Jeff Liu, Engineer, Potix Corporation
May 28, 2008

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

1. Abstract

In a previous article ZK vs. GWT, the importance and advantages of server-centric architecture were discussed and outlined. In a server-centric approach, developers simply do their programming on the server side using Java. There is no replication of business logic on the client, no hassles of asynchronous programming, and no hazards of exposing business logic on the client.

More and more Ajax frameworks are adopting this architecture, e.g. ZK, Backbase, Richface and so on. In this article, ZK will be compared against one of the 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 its server-centric architecture and event-driven model, developing web applications with ZK becomes as intuitive as programming desktops. With 170+ Ajax components and a mark-up language, designing rich user interfaces becomes as simple as authoring HTML pages. Without declaring each managedbean in configuration, ZK provides a more flexible and dynamic mechanism to achieve data accessing, annotation-databinding and variable-resolver. In recent releases of ZK, developers can even bind Java Beans into an Ajax spreadsheet application. This technical breakthrough will bring a new age to web applications development.

To learn more about how ZK works as a server-centric framework, refer to the following:

• More ZK Documentation

Also, for migrating page-based JSF to Ajax JSF, ZK offers its own JSF components set. Refer to:

• ZK JSF Components 2.0 Released

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 phase rather than the standard JSF approach of rendering all of the DOM tree. From this point, ICEfaces, Ajax Bridge, which is a mechanism to communicate between client and server side will modify the DOM tree on the client side asynchronously. As a result, an ICEfaces application still needs to go 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 by ICEfaces in order to demonstrate the difference between the frameworks.  Assume that you are coding a Google Maps Locator for a client, given the following  requirements:

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. Display the location on the Google Map and display the description as an Info Window.

Let us assume you have already implemented a magical Java class called Locator which takes a string as input and returns 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)

Gmap.zul:

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

Adopting the Direct RIA architecture, ZK is a 100% event-driven model which decouples user interface from business logic. From the above code, 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 to 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:

gmap.jspx:

	
<f:view xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core"
	xmlns:ice="http://www.icesoft.com/icefaces/component">
	<ice:outputDeclaration doctypeRoot="HTML"
		doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN"
		doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" />
	<html>
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta>
	<link href="xmlhttp/css/xp/xp.css" type="text/css" rel="stylesheet">
	<style>
		.iceGmp {
			
		}
		
		.iceGmpMapTd {
			vertical-align: top;
		}
		
		.iceGmpMapTd div.gmap {
			width: 800px;
			height: 600px;
		}
	</style>
	</link>
	</head>
	<body>
	<ice:form>
		<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}"
			zoomLevel="16">
			<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}" />
			</ice:gMapMarker>
		</ice:gMap>
	</ice:form>
	</body>
	</html>
</f:view>

	

LocatorBean.java:

   

  
   

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() {

    setLocation("");

  }

  

  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(){

    System.out.println("getLat"+_lat);

    return _lat;

  }

  

  public void setLat(String lat){

    System.out.println("setLat");

    _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;

  }

  

}
   
  
   

faces-config.xml:

	
<?xml version="1.0"?> 

<!DOCTYPE faces-config PUBLIC
    "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
    "http://java.sun.com/dtd/web-facesconfig_1_0.dtd"> 
<faces-config>
  ...
     <managed-bean>
     	<managed-bean-name>locator</managed-bean-name>
     	<managed-bean-class>com.macroselfian.gps.LocatorBean</managed-bean-class>
     	<managed-bean-scope>session</managed-bean-scope>
     </managed-bean>
     <!--  -->
      <application>
        <locale-config>
            <default-locale>en</default-locale>
        </locale-config>
    </application>
    ...
</faces-config> 
	

Icefaces inherits burdens from traditional page-based JSF. As a reault, ICEfaces developers use JSF’s backing bean concept, and the 6-phase 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 the wrapper for saving the latitude and longitude of current center?

From the 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 that is easy to learn and fast to develop with? I don’t think so. In my personal experience, if you are not familiar with JSF or if a 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 devices. But, the problem is that they are limited by browsers 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 of ZK brings benefits to those resource constrained devices. Your client devices will not be limited to robust ones with a 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

• Build Zk Mobile Twitter Application in 15 Minutes
• Google Calendar Service on ZK Mobile
• Simple and Reach - The ZK Mobile Computing

ZK on Google Adroid

More articles on ZK Android

• Extend your Web Application to Android - An Example of Google Calendar
• A Preview of ZK Mobile for Android
• Win Android $10 Million Developer Challenge by ZK Mobile for Android ;-)

5. Conclusion

Simplicity Matters!

Compared to ZK, ICEfaces is more like a JSF components set than an Ajax framework. This shows that Ajax JSF componenets such as ICEfaces don't get rid of the JSF complicated lifecycle and configuration issues. For those who already are JSF experts, Ajax JSF solutions like Richfaces and ICEfaces might be a needed painkiller for adding Ajax to projects. But, not for those who are tired of JSF and are looking for a new Ajax solution that does not suffer from the difficulty of customizing components and the complicated configurations.

From the above, one can conclude that compared to JSF, ZK is much easier to learn because of its intuitive programming style. I believe that JSF is a well-defined standard. But, it is designed for the time when people designed applications using a "page-based" pattern. When Ajax emerged and became the must-have, the time was ripe for next generation web application frameworks. Ajax is simple, but people insist on making it complicated. about the next generation web application frameworks. Ajax is simple, but people insist making it complicated.