This week I’ll be focusing on the ZK framework. It is one of two server-side component GUI frameworks in the Java AJAX universe, the other being the Echo2 framework.The basic idea behind these server-side frameworks is that you write web applications just like you write desktop GUI applications:
With ZK, you represent your application in feature-rich off-the-shelf XUL and XHTML components, and manipulate them by listening to events triggered by users, as you did for years in desktop applications. All your application codes are running at the server, while the visual representations of components and user activities at the browsers are automatically synchronized by ZK.
Though the idea is to write webapps like desktop GUI’s, ZK applications are deployed as standard servlet-based webapps — just edit the web.xml file, import in the zk libraries, add a few .zul files (ZUML) to the web content and package up as a WAR file.
Overview
A ZK application consists of two parts: a client-side Javascript engine and a server side Asynchronous Update (AU) engine. They interact something like in the following sequence diagram.
The developer’s guide gives the following execution sequence:
- When a user types an URL or clicks an hyperlink at the browser, a request is sent to the Web server. ZK loader is then invoked to serve this request, if the URL matches which ZK is configured for.
- ZK loader loads the specified page and interprets it to create proper components accordingly.
- After interpreting the whole page, ZK loader renders the result into a HTML page. The HTML page is then sent back to the browser accompanied with ZK Client Engine.
- ZK Client engine sits at the browser to detect any event triggered by user’s activity such as moving mouse or changing a value. Once detected, it notifies ZK AU Engine by sending a ZK request.
- Upon receiving ZK requests from Client Engine, AU Engine updates the content of corresponding component, if necessary. And then, AU Engine notifies the application by invoking relevant event handlers, if any.
- If the application chooses to change content of components, add or move components, AU Engine send the new content of altered components to Client Engine by use of ZK responses.
- These ZK responses are actually commands to instruct Client Engine how to update the DOM tree accordingly.
You create the UI by writing ZUML files, an XML-based language for specifying the composition of ZK pages and components as well as Java snippets to specify behavior. Here is a simple example of a tabbed pane in ZUML:
<window title=”tabbox demo” border=”normal”>
<tabbox width=”400px”>
<tabs>
<tab label=”Tab 1″/>
<tab label=”Tab 2″/>
</tabs>
<tabpanels>
<tabpanel>This is panel 1</tabpanel>
<tabpanel>This is panel 2
The second panel</tabpanel>
</tabpanels>
</tabbox>
</window>
This ends up looking like this:
ZK is just a presentation framework, i.e. you’ll have to write all of the business and persistence logic yourself. But it does do quite a good job of providing you with off-the-shelf components and effects:
- Embedded, popup and modal windows.
- Tabbed panes.
- Calendar selectors
- Text input with constraints
- Various kinds of select and combo boxes
- Sliders
- Layout components — group boxes, splitters, accordions
- Menus and toolbars
- Tables
- Trees
- Drag and drop
- Tool tips
- Context (right click) menus
- Async updates via Timers
Strengths
ZK’s biggest strength is the jump in productivity that web developers are going to experience in switching over to the component GUI model, but it does have other advantages:
- As with any server-side widget framework that uses the bridge pattern, ZK decouples the rendering logic from the presentation logic. That means that they can retarget applications to devices other than the browser, such as desktop/swing or — as Potix has announced — a version for mobile devices.
- Timer component makes async update a breeze. You still have to pay attention that your server side logic doesn’t run too long as “Events for the same desktop are processed sequentially. In other words, an event handler will block any following handlers.”
- Doesn’t try to reinvent the wheel. Makes use of existing Javascript frameworks, such as Prototype and Dojo. Eases integrating prototype-based Javascript widgets.
- ZUML makes it easy to build complex component trees. It also shortens the edit-compile-test cycle for developers.
- Allows developers to keep their business logic on the server side.
- Macro components — components written in ZUML and composed from other components — make it easy to build up more complex UI elements.
Weaknesses
There are some weaknesses as well, but most of them have more to do with platform maturity rather than design flaws:
- Documentation of both the Javascript engine and the method for writing new custom components is lacking.
- No IDE support.
- User interface state is stored in the client session. This can result in quite a bit of memory being used on the server-side, especially if lots of data and controls are combined.
- The lack of reference applications and tutorials make adopting best practices difficult.
- Look and feel is hard to control. At the very least, the details of how to change the standard “chrome” of windows, buttons, etc., needs to be documented.
- There appear to be some layout problems in some components, with slider controls floating outside of their expected positions. Could be stray positioning typos in the code.
Tomorrow we’ll look at ZK from an architectural viewpoint and see how it holds up from a performance, reliability and scalability perspective.
Cool!