Summary and Further Readings"

From Documentation
(init)
 
m
Line 1: Line 1:
 
{{ZKEssentialsPageHeader}}
 
{{ZKEssentialsPageHeader}}
 
__TOC__
 
__TOC__
 +
 +
We glimpsed into the fundamental principles behind how ZK works and we employed some of the essential features of ZK to build a sample shopping cart applications in this book.
 +
Let's recap on these elements in ZK:
 +
===Components===
 +
**Components are UI elements that an application developer piece together to build the application UI. Think LEGO, consult [http://books.zkoss.org/wiki/ZK_Component_Reference Component Reference] guide on what children components a particular component can have.
 +
**Components can be declared in ZUML (ZK User Interface Markup Language, in XML syntax), or alternatively, in Java.
 +
**Components (POJO) run on JVM at the server, and they have their counter parts (widgets - JS objects) at the client.
 +
**User activities on widgets are reflected to the components at the server; component updates are reflected back to the widgets at client.
 +
**A <javadoc>org.zkoss.zk.ui.Page</javadoc> is a "stage" where components come on and off it to play their parts and fulfill their roles.
 +
**Components are conceptually grouped in ID Spaces; we can call the <javadoc method="getFellow()">org.zkoss.zk.ui.Component</javadoc> method on one component to get another component as long as they are in the same ID Space.
 +
**By default, components declared in <javadoc>org.zkoss.zul.Window</javadoc> form an ID Space (including <javadoc>org.zkoss.zul.Window</javadoc> itself) with <javadoc>org.zkoss.zul.Window</javadoc> being the ID Space Ownder.
 +
**By default, a <javadoc>org.zkoss.zk.ui.Page</javadoc> is an ID Space Owner; any component can become the ID Space Owner by implementing <javadoc>org.zkoss.zk.ui.IdSpace</javadoc>
 +
 +
===Events===
 +
**User activities (eg. onClick) and system notifications (eg. server push) are abstracted to event objects.
 +
**Register event listeners on components so event objects can be created and forwarded.
 +
**By default, all events are send to the server for processing.
 +
**With ZK's Server+client Fusion architecture, events could also be handled at the client directly.
 +
**Event handling code can be declared as a component attribute in ZUL.
 +
**Events can be forwarded to a controller class for handling.
 +
**Event listeners can be added dynamically in Java.
 +
 +
 +
  
  
 
{{ZKEssentialsPageFooter}}
 
{{ZKEssentialsPageFooter}}

Revision as of 08:47, 2 November 2010

Stop.png This article is out of date, please refer to http://books.zkoss.org/zkessentials-book/master/ for more up to date information.

We glimpsed into the fundamental principles behind how ZK works and we employed some of the essential features of ZK to build a sample shopping cart applications in this book. Let's recap on these elements in ZK:

Components

    • Components are UI elements that an application developer piece together to build the application UI. Think LEGO, consult Component Reference guide on what children components a particular component can have.
    • Components can be declared in ZUML (ZK User Interface Markup Language, in XML syntax), or alternatively, in Java.
    • Components (POJO) run on JVM at the server, and they have their counter parts (widgets - JS objects) at the client.
    • User activities on widgets are reflected to the components at the server; component updates are reflected back to the widgets at client.
    • A Page is a "stage" where components come on and off it to play their parts and fulfill their roles.
    • Components are conceptually grouped in ID Spaces; we can call the Component.getFellow() method on one component to get another component as long as they are in the same ID Space.
    • By default, components declared in Window form an ID Space (including Window itself) with Window being the ID Space Ownder.
    • By default, a Page is an ID Space Owner; any component can become the ID Space Owner by implementing IdSpace

Events

    • User activities (eg. onClick) and system notifications (eg. server push) are abstracted to event objects.
    • Register event listeners on components so event objects can be created and forwarded.
    • By default, all events are send to the server for processing.
    • With ZK's Server+client Fusion architecture, events could also be handled at the client directly.
    • Event handling code can be declared as a component attribute in ZUL.
    • Events can be forwarded to a controller class for handling.
    • Event listeners can be added dynamically in Java.





Last Update : 2010/11/02

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