Controller"

From Documentation
Line 76: Line 76:
 
public void doAfterCompose(Component comp) {
 
public void doAfterCompose(Component comp) {
 
   super.doAfterCompose(comp); //wire variables and event listners
 
   super.doAfterCompose(comp); //wire variables and event listners
   //do whatever you want
+
   //do whatever you want (you could access wired variables here)
 
}
 
}
 
</source>
 
</source>

Revision as of 09:15, 11 November 2010

Overview

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 Listbox could be abstracted by implementing ListModel.

For typical database access, the glue logic (i.e., control) can be handled by a generic feature called 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.

In this section we will discuss how to implement a custom controller (aka., a composer).



Custom Controller

A custom controller is also know as a composer (in ZK). To implement a composer, you could extend from GenericForwardComposer, or implement Composer 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 Composer.doAfterCompose(Component).
  • 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 Composer is straightfoward: just override Composer.doAfterCompose(Component) and do whatever you want.

However, it is suggested to extend from GenericForwardComposer since the default implementation of GenericForwardComposer.doAfterCompose(Component) wires variables and event listener automatically.

For example,

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("");
    }
}

where input will be wired to a fellow named input, and onClick$submit will be registered as an event listener for an event named onClick and to a fellow named submit.

To associate a composer to a component, just specify the apply attribute to the element you want to control. For example,

<grid apply="foo.MyComposer">
    <rows>
        <row>
            <textbox id="input"/>
            <button label="Submit" id="submit"/>
            <button label="Reset" id="reset"/>
        </row>
    </rows>
</grid>

If you have to post-process the components after ZK Loader initializes them, you could override GenericForwardComposer.doAfterCompose(Component). It is important to call back super.doAfterCompose(comp). Otherwise, the wiring won't work.

public void doAfterCompose(Component comp) {
   super.doAfterCompose(comp); //wire variables and event listners
   //do whatever you want (you could access wired variables here)
}

where comp is the component that the composer is applied to. In this example, it is the grid. As the name indicates, doAfterCompose 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 : 2010/11/11

Version Date Content
     



Last Update : 2010/11/11

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