The org.zkoss.zk.ui.util.Composer interface

From Documentation

The org.zkoss.zk.ui.util.Composer interface



Since 5.0.1

A listener could implement Composer, such that it can process the creation of ZK pages like a composer specified in the apply attribute. It is also known as system-level composers.

Each time a ZK page, including ZK pages and richlets, is created, ZK will instantiate one instance for each registered system-level composer and then invoke Composer.doAfterCompose(Component) with each root component. The system-level composer is usually used to post-process ZK pages, such as adding a trademark. If you want to process only certain pages, you can check the request path by calling Desktop.getRequestPath() (the desktop instance can be found in the given component).

If the system-level composer also implements ComposerExt, it can be used to handle more situations, such as exceptions, like any other composer can do.

If the system-level composer also implements FullComposer, it will be invoked when each component is created. It provides the finest grain of control but a wrong implementation might degrade the performance.

Notice that since a new instance of the composer is created for each page, there is no threading issues.

The system-level composers are applied to richlets too. In addition, a system-level composer can implement ComposerExt to handle exceptions for a richlet, such as doCatch and doFinally. However, doBeforeCompose and doBeforeComposeChildren won't be called.
FullComposer is not applicable to richlets. In other words, system-level composers are called only for the root components.

Instantiation: An independent instance of the given class is instantiated each time before the method is invoked. It means it is thread safe, and all information stored in non-static members will be lost after called.

Last Update : 2022/03/14

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