Controller"

From Documentation
 
(19 intermediate revisions by 3 users not shown)
Line 4: Line 4:
 
The ''controller'' is a Java program that is used to glue UI (view) and Data (model) together.
 
The ''controller'' is a Java program that is used to glue UI (view) and Data (model) together.
  
For a simple UI, there is no need of controller. For example, the data of a <javadoc>org.zkoss.zul.Listbox</javadoc> could be abstracted by implementing <javadoc type="interface">org.zkoss.zul.ListModel</javadoc>.
+
A simple UI does not require any controllers. For example, the data of a <javadoc>org.zkoss.zul.Listbox</javadoc> could be abstracted by implementing <javadoc type="interface">org.zkoss.zul.ListModel</javadoc> as described in [[ZK Developer's Reference/MVC/Model|the Model section]].
  
For typical database access, the glue logic (i.e., control) can be handled by a generic feature called [[ZK Developer's Reference/Data Binding|Data Binding]]. In other words, the read and write operations can be handled automatically by a generic Data Binding, and you don't need to write the glue logic at all.
+
For typical database access, the glue logic (i.e., controller) can be handled by a generic feature called [[ZK Developer's Reference/MVVM/Data Binding|Data Binding]]. In other words, the create, read, update and delete operations (CRUD) can be handled automatically by a generic Data Binding mechanism, and you don't need to write the glue logic at all as described in [[ZK Developer's Reference/MVVM/Data Binding|the Data Binding section]].
  
In this section we will discuss how to implement a custom controller (aka., a composer).
+
If none of above fulfills your requirement, you could implement a custom controller(which is called a composer in ZK terminology). In the following sections we will discuss how to implement a custom controller in details.
  
 
{{ZKDevelopersReferenceHeadingToc}}
 
{{ZKDevelopersReferenceHeadingToc}}
 
=Custom Controller=
 
 
A custom controller is also know as a composer (in ZK).  To implement a composer, you could extend from <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>, or implement <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc> from scratch. Then, specify it in the element it wants to handle in a ZUML document.
 
 
To implement the ''logic'' to glue UI and data, a composer usually do:
 
 
*Post-process components after ZK Loader renders a ZUML document. It can be done by overriding <javadoc method="doAfterCompose(org.zkoss.zk.ui.Component)">org.zkoss.zk.ui.util.Composer</javadoc>.
 
*Handle events and manipulate components if necessary.
 
 
In additions, a composer can be used to involve the lifecycle of ZK Loader for doing:
 
 
*Exception handling
 
*Component Instantiation monitoring and filtering
 
 
A composer be configured as page-level or system-level, such that it will be called when ZK Loader has processed a ZUML document.
 
 
=GenericForwardComposer=
 
 
Implementing <javadoc type="interface">org.zkoss.zk.ui.util.Composer</javadoc> is straightfoward: just override <javadoc type="interface" method="doAfterCompose(org.zkoss.zk.ui.Component)">org.zkoss.zk.ui.util.Composer</javadoc> and do whatever you want.
 
 
However, it is suggested to extend from <javadoc>org.zkoss.zk.ui.GenericForwardComposer</javadoc> since the default implementation of <javadoc method="doAfterCompose(org.zkoss.zk.ui.Component)">org.zkoss.zk.ui.util.GenericForwardComposer</javadoc> wires variables and event listener automatically.
 
 
For example,
 
 
<source lang="java">
 
package foo;
 
import org.zkoss.zk.ui.Component;
 
import org.zkoss.zk.ui.util.GenericForwardComposer;
 
import org.zkoss.zul.*;
 
 
public class MyComposer extends GenericForwardComposer {
 
    Textbox input;
 
    Label output;
 
 
    void onClick$submit() {
 
        output.setValue(input.getValue());
 
    }
 
    void onClick$reset() {
 
        output.setValue("");
 
    }
 
}
 
</source>
 
 
where <code>input</code> will be wired to a fellow named <code>input</code>, and <code>onClick$submit</code> will be registered as an event listener for an event named <code>onClick</code> and to a fellow named <code>submit</code>.
 
 
To associate a composer to a component, just specify the [[ZUML Reference/ZUML/Attributes/apply|apply attribute]] to the element you want to control. For example,
 
 
<source lang="xml">
 
<grid apply="foo.MyComposer">
 
    <rows>
 
        <row>
 
            <textbox id="input"/>
 
            <button label="Submit" id="submit"/>
 
            <button label="Reset" id="reset"/>
 
        </row>
 
    </rows>
 
</grid>
 
</source>
 
 
If you have to post-process the components after ZK Loader initializes them, you could override <javadoc method="doAfterCompose(org.zkoss.zk.ui.Component)">org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>. It is important to call back <code>super.doAfterCompose(comp)</code>. Otherwise, the wiring won't work.
 
 
<source lang="java">
 
public void doAfterCompose(Component comp) {
 
  super.doAfterCompose(comp); //wire variables and event listners
 
  //do whatever you want
 
}
 
</source>
 
 
where <code>comp</code> is the component that the composer is applied to. In this example, it is the grid. As the name indicates, <code>doAfterCompose</code> is called after the grid and all its descendants are instantiated.
 
 
=Composer with More Control=
 
 
=Page-level Composer=
 
 
=System-level Composer=
 
 
=Version History=
 
Last Update : {{REVISIONYEAR}}/{{REVISIONMONTH}}/{{REVISIONDAY}}
 
{| border='1px' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 03:52, 10 February 2012

Overview

The controller is a Java program that is used to glue UI (view) and Data (model) together.

A simple UI does not require any controllers. For example, the data of a Listbox could be abstracted by implementing ListModel as described in the Model section.

For typical database access, the glue logic (i.e., controller) can be handled by a generic feature called Data Binding. In other words, the create, read, update and delete operations (CRUD) can be handled automatically by a generic Data Binding mechanism, and you don't need to write the glue logic at all as described in the Data Binding section.

If none of above fulfills your requirement, you could implement a custom controller(which is called a composer in ZK terminology). In the following sections we will discuss how to implement a custom controller in details.




Last Update : 2012/02/10


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