Summary and Further Readings"

From Documentation
m (Redirected page to ZK Essentials)
 
(23 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 +
#REDIRECT [[ZK Essentials]]
 +
 
{{ZKEssentialsPageHeader}}
 
{{ZKEssentialsPageHeader}}
 
__TOC__
 
__TOC__
Line 5: Line 7:
 
Let's recap on these elements in ZK:
 
Let's recap on these elements in ZK:
 
===Components===
 
===Components===
**Components are UI elements that an application developer piece together to build the application UI. <br>Think LEGO, consult [[ZK_Component_Reference]] guide on what children components a particular component can have.
+
**Components are UI elements that an application developer put them together to build the application UI, just like LEGO bricks. Consult [[ZK_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 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.
+
**Components (POJO) run on JVM on the server, and they have their counter parts (widgets - JS objects) on the client side.
**User activities on widgets are reflected to the components at the server; component updates are reflected back to the widgets at client.
+
**User activities on widgets are reflected to the components on the server. Component updates are reflected back to the widgets on the client side.
**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.
+
**A <javadoc>org.zkoss.zk.ui.Page</javadoc> is a "stage" where components come on and off 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.
+
**Components are conceptually grouped in ID Spaces; we can call the <javadoc class="none" 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, 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 Owner.
 
**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>
 
**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===
 
===Events===
 
**User activities (eg. onClick) and system notifications (eg. server push) are abstracted to event objects.
 
**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.
+
**Event listeners on components must be registered so that event objects can be created and forwarded.
**By default, all events are send to the server for processing.
+
**By default, all events are sent to the server for processing.
**With ZK's Server+client Fusion architecture, events could also be handled at the client directly.
+
**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.
 
**Event handling code can be declared as a component attribute in ZUL.
 
**Events can be forwarded to a controller class for handling.
 
**Events can be forwarded to a controller class for handling.
Line 25: Line 27:
 
===ZK MVC===
 
===ZK MVC===
 
**The ZK MVC approach provides a great separation among data (aka. model), UI and business logic (aka. control).
 
**The ZK MVC approach provides a great separation among data (aka. model), UI and business logic (aka. control).
**Under the ZK MVC pattern, UI components are declared with ZUML in ZUL files and tasks such as setting a component's data model and renderer, component manipulation, are implemented in a Controller class in Java
+
**Under the ZK MVC pattern, UI components are declared with ZUML in ZUL files. Tasks such as setting a component's data model and renderer, component manipulation are implemented in a Controller class in Java
**The controller class should extend <javadoc>org.zkoss.zki.ui.util.GenericForwardComposer</javadoc> so components declared in ZUL can be referenced in Java code and events are automatically forwarded to the controller class for handling.
+
**The controller class should extend <javadoc>org.zkoss.zki.ui.util.SelectorComposer</javadoc> so the components declared in ZUL can be referenced in Java code. Events are automatically forwarded to the controller class for handling.
  
 
===Data Display in UI: View-Model-Renderer===
 
===Data Display in UI: View-Model-Renderer===
 
**The View-Model-Renderer approach facilitates the display of a data collection in a component such as a <javadoc>org.zkoss.zul.Grid</javadoc> or <javadoc>org.zkoss.zul.Listbox</javadoc>.
 
**The View-Model-Renderer approach facilitates the display of a data collection in a component such as a <javadoc>org.zkoss.zul.Grid</javadoc> or <javadoc>org.zkoss.zul.Listbox</javadoc>.
 
**The View-Model-Renderer approach provides a great separation between data and UI.
 
**The View-Model-Renderer approach provides a great separation between data and UI.
**The Model is a wrapper for a Java Collection which serves as an interface between the ZK framework and the data collection. For example, <javadoc>org.zkoss.zul.ListModelList</javadoc> takes a list as its argument and allows the framework to access and manipulate data objects within the collection.
+
**The Model is a wrapper for a Java Collection which serves as an interface between the ZK framework and the data collection. For example, <javadoc>org.zkoss.zul.ListModelList</javadoc> takes a list as its argument, allowing the framework to access and manipulate data objects within the collection.
 
**The Renderer provides a set of instructions for associating a bean and bean's properties to UI components.
 
**The Renderer provides a set of instructions for associating a bean and bean's properties to UI components.
  
Line 38: Line 40:
 
**Annotated Data Binding allows bean properties to be declared as component attribute values so that View and Model are bound automatically without the need to specify a Renderer or creating a Model wrapper explicitly.
 
**Annotated Data Binding allows bean properties to be declared as component attribute values so that View and Model are bound automatically without the need to specify a Renderer or creating a Model wrapper explicitly.
 
**Under the hood, data binder calls a bean's getter and setter methods to retrieve, or set values in UI components.
 
**Under the hood, data binder calls a bean's getter and setter methods to retrieve, or set values in UI components.
**Data binding works with ZK MVC as such:
+
**Data binding works with ZK MVVM such as that:
**:*Controller class provides a getter method to obtain the bean, or Collection.
+
**:*ViewModel class provides a getter method to obtain the bean, or Collection.
**:*Declare the bean, or Collection, as the value for a UI component in ZUL, and the data binder will call the Controller class' getter method to append data to UI.
+
**:*Declare the bean, or Collection, as the value for a UI component in ZUL. The data binder will call the Controller class' getter method to append data to UI.
 
**By implementing the <javadoc>org.zkoss.zkplus.databind.TypeConverter</javadoc> interface, data type can be converted between UI component and data model when data binding occurs.
 
**By implementing the <javadoc>org.zkoss.zkplus.databind.TypeConverter</javadoc> interface, data type can be converted between UI component and data model when data binding occurs.
  
Line 48: Line 50:
 
**[[ZK Developer's Reference/Event Handling]]
 
**[[ZK Developer's Reference/Event Handling]]
 
**[[ZK Developer's Reference/Databinding]]
 
**[[ZK Developer's Reference/Databinding]]
**[[Small_Talks/2008/August/ZK_MVC_Made_Easy]]
+
**[[ZK Developer's Reference/MVC]]
 +
**[[Small_Talks/2008/August/ZK_MVC_Made_Easy|Small Talk: ZK MVC Made Easy]]
  
 
==Other ZK Features that Make Things Easier and More Fun==
 
==Other ZK Features that Make Things Easier and More Fun==
Material in this book touched bases on the essentials of ZK application development. Other important concepts crucial to really leveraging the benefits that ZK brings to Ajax application development includes:
+
The materials in this book touched bases on the essentials of ZK application development. Other important concepts are crucial to really leveraging the benefits that ZK which brings to Ajax application development. This includes:
**[[ZK_Developer's_Reference/Event_Handling/Client-side_Event_Listening]]
+
**[[ZK Client-side Reference/General Control/Event Listening]]
**[http://docs.zkoss.org/wiki/Macro_Component Macro Components]
+
**[[ZK Developer's Reference/UI Composing/Macro Component]]
 
 
  
 
==Performance Tips==
 
==Performance Tips==
 
Please follow these guidelines for building performance critical enterprise applications:
 
Please follow these guidelines for building performance critical enterprise applications:
**[[ZK_Developer's_Reference/Performance_Tips]]
+
**[[ZK Developer's Reference/Performance Tips]]
 
 
 
 
 
 
 
 
 
 
  
 
{{ZKEssentialsPageFooter}}
 
{{ZKEssentialsPageFooter}}

Latest revision as of 00:06, 29 March 2013

Redirect to:

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 put them together to build the application UI, just like LEGO bricks. Consult ZK_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 on the server, and they have their counter parts (widgets - JS objects) on the client side.
    • User activities on widgets are reflected to the components on the server. Component updates are reflected back to the widgets on the client side.
    • A Page is a "stage" where components come on and off to play their parts and fulfill their roles.
    • Components are conceptually grouped in ID Spaces; we can call the 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 Owner.
    • 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.
    • Event listeners on components must be registered so that event objects can be created and forwarded.
    • By default, all events are sent 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.

ZK MVC

    • The ZK MVC approach provides a great separation among data (aka. model), UI and business logic (aka. control).
    • Under the ZK MVC pattern, UI components are declared with ZUML in ZUL files. Tasks such as setting a component's data model and renderer, component manipulation are implemented in a Controller class in Java
    • The controller class should extend SelectorComposer so the components declared in ZUL can be referenced in Java code. Events are automatically forwarded to the controller class for handling.

Data Display in UI: View-Model-Renderer

    • The View-Model-Renderer approach facilitates the display of a data collection in a component such as a Grid or Listbox.
    • The View-Model-Renderer approach provides a great separation between data and UI.
    • The Model is a wrapper for a Java Collection which serves as an interface between the ZK framework and the data collection. For example, ListModelList takes a list as its argument, allowing the framework to access and manipulate data objects within the collection.
    • The Renderer provides a set of instructions for associating a bean and bean's properties to UI components.

Annotated Data Binding

    • Annotated Data Binding provides a great separation between data and UI.
    • Annotated Data Binding allows bean properties to be declared as component attribute values so that View and Model are bound automatically without the need to specify a Renderer or creating a Model wrapper explicitly.
    • Under the hood, data binder calls a bean's getter and setter methods to retrieve, or set values in UI components.
    • Data binding works with ZK MVVM such as that:
      • ViewModel class provides a getter method to obtain the bean, or Collection.
      • Declare the bean, or Collection, as the value for a UI component in ZUL. The data binder will call the Controller class' getter method to append data to UI.
    • By implementing the TypeConverter interface, data type can be converted between UI component and data model when data binding occurs.

Gaining a Deeper Understanding

To strengthen the concepts we learned in this book, please refer to the following links:

Other ZK Features that Make Things Easier and More Fun

The materials in this book touched bases on the essentials of ZK application development. Other important concepts are crucial to really leveraging the benefits that ZK which brings to Ajax application development. This includes:

Performance Tips

Please follow these guidelines for building performance critical enterprise applications:



Last Update : 2013/03/29

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