FAQ

What is the ZK project?

ZK is an open source Web development framework that enables Web applications to have both rich user experiences and low development cost as you did for years in desktop applications. ZK includes an Ajax-based event-driven engine, rich sets of XUL and XHTML components, and a markup language.

  • The event-driven engine brings the intuitive desktop programming model to Web developers.
  • The XUL and XHTML components enrich Web applications by off-the-shelf building blocks.
  • The markup language, called ZUML, makes the design of rich user interfaces as simple as authoring HTML pages.

Why do we need another framework for developing Web applications?

There are more than a dozen of frameworks for developing Web applications. Why bother to have another?

The short answer is that they are either too limited to deliver the rich user experiences, or too complex and costly to develop a Web application.

In 1994, we developed an infrastructure, inspired by zApp and OWL, for developing an accounting system for Windows. In 2000, we developed another infrastructure, inspired by Struct and WebWorks, for developing another accounting system for J2EE. After coaching and watching the development of both systems, we found that not only the Web edition required much higher programming skills and prerequisites, but also its total cost is four times more than the client/server one. Worse of all, the user experiences reminded us the age of green terminals, though the look, after decorating with proper images and CSS, is modern and fresh.

We start wondering whether it is intrinsic, or the programming model is simply inadequate. Looking back the success of desktop applications in 1990s, the event-driven, component-based programming model played a big role. Being blessed with the ease to learn and develop, it is the standard and best way to handle interactive and responsive user interfaces. Can we apply this model to Web applications? After using ZK to develop several commercial projects, we believe we got the answer.


What are the goals of the ZK project?

  • The same or better rich and interactive user interfaces as that of desktop applications.
  • The same or better simplicity to develop Web applications as that of desktop applications.
  • A good architecture and community to encourage collaboration.

What is the current status? Is it really simple and rich?

Download and try it. Judge for yourself.

  • Over 70 XUL and 80 XHTML components are supported, including list boxes, tree, drag-and-drop, auto-completion, sliders, timer, combo boxes, audio and many others.
  • Server centric. Visual representation and content are synchronized automatically between clients and servers.
    The best way to use Ajax is not to know its existence.
  • Script in Java and EL expressions. No JavaScript. No compilation. No proprietary expressions or scripts.
  • Simple threading model. No prerequisite of handling threading and concurrent accesses. Yet no limitation to apply any sophisticated threading on your demand.
  • Flexible threading model. Easy to suspend and resume your application without blocking users. Supports true server-side modal dialogs.
  • Easy to develop new components with supports of template and synchronization technologies.
  • Easy to encapsulate a pure-client JavaScript widget into a server-centric Java component, such as FCKeditor and Dojo.
  • Easy to power applications with versatile components, as simple as dropping jar files into the class path.
  • An open community to share components, themes and utilities.
  • Zero configurations and compilation. Maintaining ZUML pages is as easy as maintaining HTML pages.
  • No prerequisite of any design patterns. For fast protyping, you could embed Java codes directly in ZUML pages. For sophisticated applications, you could apply MVC or others. The choice is yours, not framework.

What browsers are supported?

ZK supports Internet Explorer 6+/7, Firefox 1+, Safari 2+, Mozilla 1+, Opera 9+ and Camino 1+.


What servers are supported?

ZK runs on any Web server that supports Servlet 2.3+ and JVM 1.4+.


Any plug-in required?

Like other Ajax solutions, users need not to pre-install any plug-in.


Why XUL? Why not Swing?

There are at least three approaches to implement user interfaces: programming, authoring with a graphical tool, and declaring in a markup language. The first is important for implementing sophisticated user interfaces. The later two approaches are important for non-programmers. To maximize the productivity, ZK chose to support both programming and markup languages, and allows developers to meld them smoothly. The graphic authoring tool will be supported later.

Instead of inventing proprietary components and languages, we chose XUL as the first language to support (XHTML is the second). ZK is not tied to XUL. It is designed to be neutral in regard to markup languages. In other words, additional sets of components and markup languages, such as XAML, could be added independently.

Swing is powerful if you are familiar with Java programming. However, it is complex for novice programmers to learn and use, though there are authoring tools to simplify the design.


Does ZK require browsers support XUL?

ZK doesn't count on whether a browser supports XUL. For sake of cross-browser compatibility, ZK generates HTML tags according what XUL or XHTML components are used. For browser's viewpoint, it is only standard HTML, CSS and JavaScript codes.

On the other hand, ZK doesn't limit you from using the native support of XUL by the browser, as long as a corresponding component set is provided.


Does ZK support browsers without JavaScript?

Currently, we support only browsers with decent support of DOM and JavaScript. However, more and more devices, say smart phones, are packed with J2ME, and many of them only have a lame browser. Thanks to the architecture advantage, a J2ME edition or similar could be ported in the future, such that your applications remain intact.


Can I customize the look and feel?

The look and feel is controlled by CSS which could be customized easily.

A component could support different molds whose appearance could be dramatically, yet the programming API remains the same. So your application remains intact. For example, a tab box has both regular and accordion-type molds.


What prerequisite knowledge do I need before using it?

After observing the success of PHP and Ruby, we deliberately made ZK easy to learn and use. To start, you need only to know basics of Java and XUL. You don't need to know object-oriented (until you are applying MVC or other design patterns).

For UI designers or prototype makers, you don't even need to know (and use) Java at all. If you prefer to manipulate HTML directly, you don't need to know (and use) XUL at all.


Do I need to give up the framework what I spent countless hours to work with?

We intend to replace the presentation tier of existent frameworks, but we understand and respect your investments on different frameworks. You don't need to give them up. You need only to rewrite a portion of a page that requires the rich user interface. Any JSP, HTML and portlet pages could include ZUML pages, vice versa.

In addition, ZK provides a filter to let you post-process responses generated by other technologies. ZK also provides a portlet to let you integrate ZUML page into any JSR-168 compliant portal.


Is it easy to develop a new component?

It depends on the functionality of a component. It is never easy to develop a Excel-like component. However, most components could be implemented easily with ZK. Actually, most of 60 XUL components are implemented in 2 man-months (by, of course, a seasoned programmer).

To simplify the development of components, ZK supports any kind of template technologies, such as JSP, as long as it could be addressed by an URI. In addition, a set of well-designed utilities are supported to simplify the synchronization of the component content at server with its visual presentation at the client.

To eliminate the compilation hurdles and to allow component being packaged as a jar file instead of a war fie, ZK delivers a template technology called Dynamic Servlet Page (DSP). It is similar to JSP, yet interpreted dynamically at the run time. All components from the ZK's official distribution are implemented in DSP and packaged as jar files.


Can I use my favorite Ajax components, such as FCKeditor and Dojo?

One of best things which happen to developers in recent years is the booming of the open source community. There are plenty of brilliant Ajax components and widgets available.

How to leverage them simply is one of key factors for designing ZK architecture. As depicted in Integrating FCKeditor, we integrate FCKeditor in less than 200 lines, including Java, JavaScript and HTML, and Dojo in less than 300 lines.


What do you mean by no compilation required? Won't it be slow?

The use of ZK is as simple as drop-and-go, as you did for static HTML pages. To deploy ZUML pages, you simply copy them to the proper location. ZK detects and reloads modified pages. After loaded, ZK parses a ZK page into an intermediate format that can be processed very fast. The intermediate format is cached so the performance is not an issue.

Unlike JSP, ZK doesn't count on Java compiler. Of course, if you are using a component from a third party or in-house that uses JSP, Java compiler is required.


Many Ajax solutions use bootstrap technologies to load HTML pages. Will it be slow because of round-trips?

Round-trip is a common challenge to Web applications, especially if clients are thousands miles away. Thus, ZK uses a separate rendering phase to send back the whole page in one response. The latency is no different from static HTML page with similar size.

However, ZK, like other Ajax solutions, has many JavaScript codes. ZK has modulized them such that only required modules are loaded when relevant components are used. In additions, browsers cache these JavaScript codes, so they are loaded only at the first time and reused thereafter among pages.


Will it be slow if everything is done at the server?

Server-centric is from the viewpoint of the applications. How to distribute the loading between client and server depends on the implementation of components.

For example, an edit box is a component that does almost everything at client (by the browser's native support). Similarly, list boxes and trees also do most of things in the client (by JavaScript). Unless you want to replicate business logic into the client, the performance is no different between ad-hoc Ajax apps and the ZK approach (for achieving rich user interfaces).

Of course, a component developer has an option to shorten the time to market by implementing most of codes in the server (i.e., with minimal JavaScript codes). The performance of using such component might be not scalable enough, but the component developer could improve it anytime without breaking application's codes.


I heard Ajax is not mature and JavaScript causes severe memory leaks. Are they true?

Manipulating DOM with JavaScript is painful, because of incompatibility issues and buggy implementations among browsers. Inadequate use of JavaScript does cause severe memory leaks. This is one of reason you need a framework that prevents you from coding in JavaScript. This is one of reason we open ZK. The more people use, the more stable the framework is.


Will ZK be obsolete, if IE supports XUL, or Firefox supports XAML?

No. The philosophy is quite different. ZK is a server-centric solution. All components developers manipulate are running at the server. To show a list of active customers, simple query the database and creates list items to represent each of them. All are at the server. The client technology is totally transparent to Web developers who use ZK. Just like you don't care what the graphic card is used and how it communicates with OS, when developing desktop applications.

On the other hand, XUL supported natively by Firefox is a pure client-side technology. It could be a better solution, if your application doesn't talk to the server. If you need, say, fill a list box by querying a database, you have to write all the codes to communicate between the browser and the server.


Can I make software with ZK open source and release it under the GNU GPL, LGPL, or BSD license?

Yes. The GNU GPL, GPL-compatible licenses, or any other approved open source license will do. The FSF.org and OpenSource.org web sites list approved software licenses (OSI-approved open source licenses).

We want OSI-approved open source software applications to be able to use specified GPL-licensed ZK despite that not all OSI-approved open source licenses are compatible with with version 2 of the GNU GPL. Potix grants you the right beyond the GPL as special exception. In return, you must, on request, make the complete source code available to Potix and other recipients of your application.

More about licensing.