ZK Developer's Reference/Performance Tips/Use Compiled Java Codes

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).

<syntax lang="xml">

<window apply="foo.MyComposer">

//omitted </syntax>

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,

<syntax lang="xml">

 <button label="OK" onClick="doSomething()"/>

</syntax>

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.

<syntax lang="xml" > <zscript deferred="true"> </zscript> </syntax>

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:

<syntax lang="xml" > <window id="w">

   <zscript deferred="true">
    void addMore() {
        new Label("More").setParent(w);
    }
   </zscript>
   <button label="Add" onClick="addMore()"/>

</window> </syntax>

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.

<syntax lang="xml" > <window onCreate="init()"> </syntax>

Rather, it is better to rewrite it as

<syntax lang="xml" > <window use="my.MyWindow"> </syntax>

Then, prepare MyWindow.java as shown below.

<syntax lang="java" >

package my;
public class MyWindow extends Window {
    public void onCreate() { //to process the onCreate event
...

</syntax>

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.

<syntax lang="java" >

package my;
public class MyWindow extends Window implements org.zkoss.zk.ui.ext.AfterCompose {
    public void afterCompose() { //to initialize the window
...

</syntax>

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.

<syntax lang="xml" > <window id="w">

   <button label="OK" onClick="w.onOK"/>

</syntax>

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.

<syntax lang="xml" > <window>

   <button label="OK" forward="onOK"/>

</syntax>

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,

<syntax lang="java"> public class MyComposer extends GenericForwardComposer {

   public MyComposer() {
       super('$', false, false);
       //omitted
   }

} </syntax>

---

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.

Version History

Version	Date	Content