Using any possible component property name as a variable name in a ZUL page or any component based dynamic web page technology is always a bad idea .
This can be justified by the following reasons:
1. Variable resolve (lookup) in any dynamic web page is normally based on the stack concept . Imagine a ZUL page that looks like the following:

<window id="a">
    <zscript>
        var str = "xyz";
    </zscript>
    <window id="b">
        <window id="c">
            <zscript>
                System.out.println(str);//FIRST
            </zscript>
         </window>
     </window>
</window>

The generated output is  “xyz” (lookup c->b->a)

At first, ZK tries to get “str” from scope “c” and when “str” cannot be found, ZK will expand its search region to the parent scope to see if there’s a match.
This concept is used in all kinds of dynamic web pages, hence, if the component tree variable resolve mechanism does not support stack concept, it will be very inconvenient to program.-

2. Nowadays, designing UI Component sets in Java are all based on Java bean convention principles.
(ex: default constructor, POJOs)
We follow these conventions because we want to leverage language reflection mechanisms such as:
– Bean factory utility
– Variable wiring(dynamic properties)
– Event handler registration (ex: onClick() of a button).

For example, imagine a ZUL file containing two variables

1. src=”test.jpg”;

2. mode=”debug”;

Try using “variable wiring mechanism” for components such as <image> or <window>
The image’s “src” would be wired with the value “test.jpg” while the window’s “mode” would be set to “debug”.
The result on the image might be something you expect, but the <window mode=”debug”> will definitely cause an “IllegalArgumentException” due to an incorrect input of data.

 

With the current ZK5 (5.0.5 or later), in order to prevent this by default for all ZK component’s attributes,  a new configuration called “library-property) is introduced in zk.xml:

<library-property>
    <name>org.zkoss.zk.ui.wire.zul.enabled</name>
    <value>false</value>
</library-property>
Default value is set as false, however, even with this protection, if you override any existing setter methods of ZK, the problem will still occur like the following example:
<zk>
	<zscript><![CDATA[
		String mode = "debug";
		class MyWin extends Window{
			public MyWin(){
				Components.wireVariables(this, this);
			}
			public void setMode(String mode)throws InterruptedException{
				super.setMode(mode);
			}
		}
	]]></zscript>
	<window use="MyWin"/>
</zk>

Consequently, the best principle of variable naming in ZK or any dynamic web page is:

Never use any common variable names!

 

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Leave a Reply