Use Compiled Java Codes"

From Documentation
m (remove empty version history (via JWB))
 
(19 intermediate revisions by 5 users not shown)
Line 4: Line 4:
 
= Not to Use zscript for Better Performance =
 
= 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. It is suggested to use zsript only for fast prototyping, POC, or small projects. For large website, it is suggested to use [[ZK Developer's Reference/MVC|ZK MVC]] instead. For example,
+
It is convenient to use zscript in ZUML, but it comes with a price: slower performance. The degradation varies from one application to another. It is suggested to use zscript only for fast prototyping, POC, or small projects. For large websites, it is suggested to use [[ZK Developer's Reference/MVC|ZK MVC]]/[http://books.zkoss.org/zk-mvvm-book/8.0/index.html ZK MVVM] instead. For example, with ZK MVC
  
<syntax lang="xml">
+
<syntaxhighlight line lang="xml">
 
  <window apply="foo.MyComposer">
 
  <window apply="foo.MyComposer">
 
//omitted
 
//omitted
</syntax>
+
</syntaxhighlight>
  
Then, you can handle all events in <code>foo.MyComposer</code>. By the use of [[ZK Component Reference/Common Operations/Event Handling/Event Listening#Composer_and_Event_Listener_Autowiring | auto-wiring]], handling events is very straightforward.
+
You can handle all events and components in <code>foo.MyComposer</code>. By the use of [[ZK Component Reference/Common Operations/Event Handling/Event Listening#Composer_and_Event_Listener_Autowiring | auto-wiring]], it is straightforward to handle events and components.
  
== Event Handler Is Zscript ==
+
== Event Handler Is zscript ==
  
In additions to <tt>zscript</tt>, [[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,
+
In addition to the <code>zscript</code> element, [[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">
+
<syntaxhighlight line lang="xml">
 
   <button label="OK" onClick="doSomething()"/>
 
   <button label="OK" onClick="doSomething()"/>
</syntax>
+
</syntaxhighlight>
  
where <tt>doSomething()</tt> is interpreted as <tt>zscript</tt>. Thus, for better performance, they should be replaced too.
+
where <code>doSomething()</code> is interpreted as <code>zscript</code>. Thus, for better performance, they should be replaced too.
 +
 
 +
==Turn off the use of zscript==
 +
{{versionSince|5.0.8}}
 +
 
 +
If you decide not to use zscript at all, you could turn on [[ZK Configuration Reference/zk.xml/The system-config Element/The disable-zscript Element|the disable-script configuration]] as follows, such that an exception will be thrown if zscript is used.
 +
 
 +
<source lang="xml">
 +
<system-config>
 +
<disable-zscript>true</disable-zscript>
 +
</system-config>
 +
</source>
  
 
= Use the deferred Attribute =
 
= Use the deferred Attribute =
If you still need to write zscript codes, you can specify the <tt>deferred</tt> attribute to defer the evaluation of zscript codes as follows.
+
If you still need to write zscript codes, you can specify the <code>deferred</code> attribute to defer the evaluation of zscript codes as follows.
  
<syntax lang="xml" >
+
<syntaxhighlight line lang="xml" >
 
<zscript deferred="true">
 
<zscript deferred="true">
 
</zscript>
 
</zscript>
</syntax>
+
</syntaxhighlight>
  
By specifying the <tt>deferred</tt> 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. This saves memory and speeds up page rendering.
+
By specifying the <code>deferred</code> attribute, the zscript codes it contains will not be evaluated when ZK renders a page. It means that the interpreter won't be loaded when ZK renders a page. This saves memory and speeds up page rendering.
  
 
In the following example, the interpreter is loaded only when the button is clicked:
 
In the following example, the interpreter is loaded only when the button is clicked:
  
<syntax lang="xml" >
+
<syntaxhighlight line lang="xml" >
 
<window id="w">
 
<window id="w">
 
     <zscript deferred="true">
 
     <zscript deferred="true">
Line 44: Line 55:
 
     <button label="Add" onClick="addMore()"/>
 
     <button label="Add" onClick="addMore()"/>
 
</window>
 
</window>
</syntax>
+
</syntaxhighlight>
  
 
== The deferred Attribute and the onCreate Event ==
 
== The deferred Attribute and the onCreate Event ==
It is worth to notice that, if the <tt>onCreate</tt> event listener is written in zscript, the deferred option mentioned in the previous second becomes ''useless''. It is because the <tt>onCreate</tt> event is sent when the page is loaded. In other words, all deferred zscript will be evaluated when the page is loaded if the <tt>onCreate</tt> event listener is written in zscript as shown below.
+
It is worth to notice that, if the <code>onCreate</code> event listener is written in zscript, the deferred option mentioned in the previous section becomes ''useless''. It is because the <code>onCreate</code> event is sent when the page is loaded. In other words, all deferred zscript will be evaluated when the page is loaded if the <code>onCreate</code> event listener is written in zscript as shown below.
  
<syntax lang="xml" >
+
<syntaxhighlight line lang="xml" >
 
<window onCreate="init()">
 
<window onCreate="init()">
</syntax>
+
</syntaxhighlight>
  
 
Rather, it is better to rewrite it as
 
Rather, it is better to rewrite it as
  
<syntax lang="xml" >
+
<syntaxhighlight line lang="xml" >
 
<window use="my.MyWindow">
 
<window use="my.MyWindow">
</syntax>
+
</syntaxhighlight>
  
Then, prepare <tt>MyWindow.java</tt> as shown below.
+
Then, prepare <code>MyWindow.java</code> as shown below.
  
<syntax lang="java" >
+
<syntaxhighlight line lang="java" >
 
  package my;
 
  package my;
 
  public class MyWindow extends Window {
 
  public class MyWindow extends Window {
 
     public void onCreate() { //to process the onCreate event
 
     public void onCreate() { //to process the onCreate event
 
  ...
 
  ...
</syntax>
+
</syntaxhighlight>
 
   
 
   
If you prefer to do the initialization right after the component (and all its children) is created, you can implement the <javadoc type="interface">org.zkoss.zk.ui.ext.AfterCompose</javadoc> interface as shown below. Note: the <tt>afterCompose</tt> method of the <tt>AfterCompose</tt> interface is evaluated at the Component Creation phase, while the <tt>onCreate</tt> event is evaluated in the Event Processing Phase.
+
If you prefer to do the initialization right after the component (and all its children) is created, you can implement the <javadoc type="interface">org.zkoss.zk.ui.ext.AfterCompose</javadoc> interface as shown below. Note: the <code>afterCompose</code> method of the <code>AfterCompose</code> interface is evaluated at the Component Creation phase, while the <code>onCreate</code> event is evaluated in the Event Processing Phase.
  
<syntax lang="java" >
+
<syntaxhighlight line lang="java" >
 
  package my;
 
  package my;
 
  public class MyWindow extends Window implements org.zkoss.zk.ui.ext.AfterCompose {
 
  public class MyWindow extends Window implements org.zkoss.zk.ui.ext.AfterCompose {
 
     public void afterCompose() { //to initialize the window
 
     public void afterCompose() { //to initialize the window
 
  ...
 
  ...
</syntax>
+
</syntaxhighlight>
  
 
= Use the forward Attribute =
 
= 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 <tt>onClick</tt> event is sent to the button. Developers usually forward the event to the window by the use of the <tt>onClick</tt> event listener as follows.
+
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 a user clicks a button, the <code>onClick</code> event is sent to the button. However, developers may need to forward the event to the window component by the use of the <code>onClick</code> event listener as follows.
 +
 
 +
<source lang="xml" >
 +
<window id="w" onOK='alert("on OK")'>
 +
    <button label="OK" onClick='Events.postEvent("onOK", w, null)'/>
 +
</window>
 +
</source>
  
<syntax lang="xml" >
+
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 <code>EventListener</code> or by specifying the <code>forward</code> attribute as follows.
<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 <tt>EventListener</tt> or by specifying the <tt>forward</tt> attribute as follows.
 
  
<syntax lang="xml" >
+
<source lang="xml" >
<window>
+
<window apply="foo.MyComposer">
 
     <button label="OK" forward="onOK"/>
 
     <button label="OK" forward="onOK"/>
</syntax>
+
</window>
 
+
</source>
= GenericForwardComposer and GenericAutowireComposer =
 
 
 
If <tt>zscript</tt> is ever used, the autowiring of <javadoc>org.zkoss.zk.ui.util.GenericForwardComposer</javadoc> and <javadoc>org.zkoss.zk.ui.util.GenericAutowireComposer</javadoc> might be slow because it has to look for the variables defined in <tt>zscript</tt>.
 
 
 
Unless you really declare a data member in your composer that should be wired to a <tt>zscript</tt> variable, it is safe to turn the wiring of <tt>zscript</tt> variables off. It can be done by passing false to the second and third arguments of <javadoc method="GenericAutowireComposer(char, boolean, boolean)">org.zkoss.zk.ui.util.GenericAutowireComposer</javadoc>. For example,
 
 
 
<syntax lang="java">
 
public class MyComposer extends GenericForwardComposer {
 
    public MyComposer() {
 
        super('$', false, false);
 
        //omitted
 
    }
 
}
 
</syntax>
 
 
 
<blockquote>
 
----
 
Notice that, since it is rarely needed to look for a <tt>zscript</tt> variable, the default constructor (<javadoc method="GenericAutowireComposer()">org.zkoss.zk.ui.util.GenericAutowireComposer</javadoc>) assumes false in ZK 6. However, they are default to true in ZK 5.0 for better backward compatibility.
 
</blockquote>
 
  
=Version History=
 
  
{| border='1px' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 10:24, 5 February 2024


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 to another. It is suggested to use zscript only for fast prototyping, POC, or small projects. For large websites, it is suggested to use ZK MVC/ZK MVVM instead. For example, with ZK MVC

1  <window apply="foo.MyComposer">
2 //omitted

You can handle all events and components in foo.MyComposer. By the use of auto-wiring, it is straightforward to handle events and components.

Event Handler Is zscript

In addition to the zscript element, the event handler declared in a ZUL page is also interpreted at the runtime. For example,

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

where doSomething() is interpreted as zscript. Thus, for better performance, they should be replaced too.

Turn off the use of zscript

Since 5.0.8

If you decide not to use zscript at all, you could turn on the disable-script configuration as follows, such that an exception will be thrown if zscript is used.

<system-config>
	<disable-zscript>true</disable-zscript>
</system-config>

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.

1 <zscript deferred="true">
2 </zscript>

By specifying the deferred attribute, the zscript codes it contains will not be evaluated when ZK renders a page. It means that the interpreter won't be loaded when ZK renders a page. This saves memory and speeds up page rendering.

In the following example, the interpreter is loaded only when the button is clicked:

1 <window id="w">
2     <zscript deferred="true">
3      void addMore() {
4          new Label("More").setParent(w);
5      }
6     </zscript>
7     <button label="Add" onClick="addMore()"/>
8 </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 section 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.

1 <window onCreate="init()">

Rather, it is better to rewrite it as

1 <window use="my.MyWindow">

Then, prepare MyWindow.java as shown below.

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

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.

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

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 a user clicks a button, the onClick event is sent to the button. However, developers may need to forward the event to the window component by the use of the onClick event listener as follows.

<window id="w" onOK='alert("on OK")'>
    <button label="OK" onClick='Events.postEvent("onOK", w, null)'/>
</window>

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 apply="foo.MyComposer">
    <button label="OK" forward="onOK"/>
</window>




Last Update : 2024/02/05

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