Summary and Further Readings"
Tmillsclare (talk | contribs) m (Redirected page to ZK Essentials) |
|||
(13 intermediate revisions by 4 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 | + | **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 | + | **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 | + | **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 | + | **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 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. | **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 Owner. | **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. | ||
Line 16: | Line 18: | ||
===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. | ||
− | ** | + | **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. | **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. | ||
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 | + | **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. | + | **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 | + | **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 | + | **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 | + | **:*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== | ||
− | + | 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 Client-side Reference/General Control/Event Listening]] | **[[ZK Client-side Reference/General Control/Event Listening]] | ||
**[[ZK Developer's Reference/UI Composing/Macro Component]] | **[[ZK Developer's Reference/UI Composing/Macro Component]] |
Latest revision as of 00:06, 29 March 2013
Redirect to:
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: