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
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.