Architecture Overview

From Documentation


DocumentationZK Developer's ReferenceOvertureArchitecture Overview
Architecture Overview


Architecture-s.png

Application Developer's Perspective

A ZK application runs at the server. It could access the backend resources, assemble UI with components, listen to user's activity, and then manipulate components to update UI. All are done at the server. The synchronization of the states of the components between the browser and the server is done automatically by ZK, and transparent to the application.

When running at the server, the application can access the full stack of Java technology. User activities are, including Ajax and Server Push, abstracted to event objects. UI are composed by POJO-like components. It is the most productive approach to develop a modern Web application.

With ZK's Server+client Fusion architecture, your application won't stop at the server. The application could enhance the interactivity by adding optional client-side functionality, such as client-side event handling, visual effect customizing, and even UI composing without the server-side code. ZK enables the seamless fusion ranging from pure server-centric, to pure client-centric. You could have the best of two worlds: productivity and flexibility.

Component Developer's Perspective

Each UI object in ZK consists of a component and a widget. A component is a Java object running at the server which represents a UI object which can be manipulated by a Java application. A component has all the behavior of a UI object except it has no visual part. A widget is a JavaScript object[1] running at the client. This object represents the UI object which interacts with the user. Therefore, a widget usually has a visual appearance, and handles events happening at the client.

The relationship between a component and a widget is one-to-one. However, if a component is not attached to a page, it won't have the corresponding widget at the client. On the other hand, the application is allowed to instantiate widgets at the client directly without the corresponding component.

How to synchronize the states and distribute the load is really up to the component. ZK Client Engine and Update Engine work together to provide an elegant and robust channel to simplify the implementation.

For example, assume we want to implement a component that allows a user to click on a DOM element to show some detailed information of a component. There are at least two approaches to implement it. First, we could load the detailed information to the client when the widget is instantiated, and then show the detail with pure-client code. Alternatively, we might prefer not to load the detailed information at the beginning, and then send a request back to the server for fulfilling the detail when the user clicks on it.

Obviously, the first approach requires more bandwidth for the initial request but responses faster when users click on it. However, it is generally transparent to the application developers, and the implementation of a component can be enhanced later as the project goes.

  1. ↑ It depends on the client. For Ajax-enabled browsers, it is a JavaScript object. For ZK Reach for Android, it is a Java object running on an Android device.

Execution Flow of Loading a Page

  1. When a user types a URL or clicks a hyperlink at the browser, a request is sent to the Web server. If the request URL matches ZK's configured URL pattern[1], the ZK loader is then invoked to serve this request.
  2. ZK loader loads the specified page and interprets it to create proper components accordingly[2].
  3. 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[3].
  4. ZK Client engine renders the widgets into DOM elements and inserts the DOM elements into the browser's DOM tree to make them visible to users.
  5. Then, ZK Client engine sits at the browser to serve the requests made by user, widgets or the application. If it is going to another page, the execution flow starts over again. If it is going to send Ajax request back, another execution flow starts as described in the following section.
  1. ↑ For more information, please refer to ZK Configuration Reference
  2. ↑ If URL is mapped to a richlet, the richlet will be called to handle all UI composition. For more information, please refer to Richlet.
  3. ↑ ZK Client Engine is written in JavaScript. Browsers will cache ZK Client engine, so ZK Client engine is usually sent only once at the first visit.

Execution Flow of Serving an Ajax Request

  1. The execution flow is started by a widget or the application; usually caused by user's activity (or application's requirement). It is usually done by posting a client-side event (Event) to a widget (Widget.fire(Event, int)).
  2. The event is then bubbled up to the widget's parent, parent's parent, and finally ZK Client engine[1]. ZK Client engine, then, decides whether and when to send the event back to the server in an Ajax request.
  3. If necessary, ZK Client engine sends an Ajax request to ZK Update engine at the server[2].
  4. Upon receiving Ajax requests, ZK Update engine invoke ComponentCtrl.service(AuRequest, boolean) for handling the request.
  5. The handling is up to a component. But, it usually updates the states, if necessary, and then notifies the application by posting events (Events.postEvent(Event)).
  6. If any event is posted, ZK Update engine will process them one-by-one by invoking the event listeners, if any.
  7. The event listener, provided by an application, might choose to update the backend resources, to update the components or to post other events.
  8. Finally, ZK Update engine collects all updates of components, including states change, attachment and detachment, optimize it, and then send back a collection of commands back to the client.
  9. ZK Client engine evaluates each of these commands to update the widgets accordingly. And, the widgets will update the browser's DOM tree to make them available to the user.
  1. ↑ A widget could choose to stop this bubble-up propagation by use of Event.stop(Map)
  2. ↑ From server's viewpoint, an Ajax request is yet another HTTP request.

When to Send an Ajax Request

When ZK Client engine receives a bubbled-up client-side event (Event), it will decide whether and when to send it back to the server for further processing.

  1. If there is a non-deferrable event listener registered at the server, the request is sent immediately.
  2. If there is a deferrable event listener registered at the server, the request will be queued at the client and will be sent when another event is triggered and a non-deferrable event listener registered for it.
  3. If the widget declares the event is important (ComponentCtrl.CE_IMPORTANT), the event will be queued for later transmitting too.
  4. If none of the above case or the widget has no corresponding component at the server, the event is dropped.

A non-deferred event listener is an event listener (EventListener) that doesn't implement Deferrable. In other words, to minimize the traffic from the client, you might implement an event listener with Deferrable if applicable.

Version History

Last Update : 2011/03/15


Version Date Content
     



Last Update : 2011/03/15

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.


Retrieved from "https://www.zkoss.org/_w/index.php?title=ZK_Developer%27s_Reference/Overture/Architecture_Overview&oldid=17875"