Use Compiled Java Codes
This documentation is for an older version of ZK. For the latest one, please click here.
Not to Use zscript for Better Performance
It is convenient to use zscript in ZUML, but it comes with a price: slower performance. The degradation varies from one application from another. For large website, it is suggested not to use zscript for better performance. It can be done easily by use of ZK MVC (by implementing a composer to register event listeners and so on).
<window apply="foo.MyComposer">
//omitted
Then, you can handle all events in foo.MyComposer
. By use of auto-wiring, the handling of events is straightforward.
Event Handler Is Zscript
In additions to zscript, [[ZK Component Reference/Common Operations/Event Handling/Event Listening#Declare_an_Event_Handler_in_a_ZUL_page | the event handler declared in a ZUL page] is also interpreted at the runtime. For example,
<button label="OK" onClick="doSomething()"/>
where doSomething() is interpreted as zscript. Thus, for better performance, they shall be replaced too.
Use the deferred Attribute
If you still need to write zscript codes, you can specify the deferred attribute to defer the evaluation of zscript codes as follows.
<zscript deferred="true">
</zscript>
By specifying the deferred attribute, the zscript codes it contains will not be evaluated when ZK renders a page. It means the interpreter won't be loaded when ZK renders a page. It saves memory and speeds up the page rendering.
In the following example, the interpreter is loaded only when the button is clicked:
<window id="w">
<zscript deferred="true">
void addMore() {
new Label("More").setParent(w);
}
</zscript>
<button label="Add" onClick="addMore()"/>
</window>
The deferred Attribute and the onCreate Event
It is worth to notice that, if the onCreate event listener is written in zscript, the deferred option mentioned in the previous second becomes useless. It is because the onCreate event is sent when the page is loaded. In other words, all deferred zscript will be evaluated when the page is loaded if the onCreate event listener is written in zscript as shown below.
<window onCreate="init()">
Rather, it is better to rewrite it as
<window use="my.MyWindow">
Then, prepare MyWindow.java as shown below.
package my;
public class MyWindow extends Window {
public void onCreate() { //to process the onCreate event
...
If you prefer to do the initialization right after the component (and all its children) is created, you can implement the AfterCompose interface as shown below. Note: the afterCompose method of the AfterCompose interface is evaluated at the Component Creation phase, while the onCreate event is evaluated in the Event Processing Phase.
package my;
public class MyWindow extends Window implements org.zkoss.zk.ui.ext.AfterCompose {
public void afterCompose() { //to initialize the window
...
Use the forward Attribute
To simplify the event flow, ZK components usually send the events to the component itself, rather than the parent or other targets. For example, when an user clicks a button, the onClick event is sent to the button. Developers usually forward the event to the window by use of the onClick event listener as follows.
<window id="w">
<button label="OK" onClick="w.onOK"/>
As suggested in the previous sections, the performance can be improved by not using zscript at all. Thus, you can rewrite the above code snippet either with EventListener or by specifying the forward attribute as follows.
<window>
<button label="OK" forward="onOK"/>
GenericForwardComposer and GenericAutowireComposer
If zscript is ever used, the autowiring of GenericForwardComposer and GenericAutowireComposer might be slow because it has to look for the variables defined in zscript.
Unless you really declare a data member in your composer that shall be wired to a zscript variable, it is safe to turn the wiring of zscript variables off. It can be done by passing false to the second and third arguments of GenericAutowireComposer.GenericAutowireComposer(char, boolean, boolean). For example,
public class MyComposer extends GenericForwardComposer {
public MyComposer() {
super('$', false, false);
//omitted
}
}
Notice that, since it is rarely needed to look for a zscript variable, the default constructor (GenericAutowireComposer.GenericAutowireComposer()) assumes false in ZK 5.5. However, they are default to true in ZK 5.0 for better backward compatibility.
See Also
Discussion of this article: Talk:Performance_tip
From ZK smalltalk:
From ZK forum:
- GenericForwardComposer slow when used with ZScript
- ZK App run slow in a Citrix like environment
- Slow page
- slow performance when dynamic paging
- Best practice and performance for menu tree | zul vs. java
- zkmax - performance enhancement version of ZUL - what does it mean?
- How to testify zk's performance in big project?