Myth I – UI Component Control is Cumbersome Due to ID Space Constraints

Misconceptions often get in our way of recognizing the true value of things. In the case of building enterprise grade Web applications using ZK, when programmers work around the framework convention instead of working with it, they make applications more complicated than necessary.

In this series of blogs, we’ll get to de-”myth”-tify the unwarranted complexity and expose the friendliness that’s pervasive in ZK’s design.

Background

The concept of ID Space was developed to address the nuisance of having to assign each component with a unique ID.

ID Space groups components into subsets so they could be easier to manage when the number of components becomes large; similar to the idea of a namespace. In an enterprise grade Web application, the numerous pages for meshing are more than likely composed not by the same developer and hence difficult to keep; ID Space is a viable solution.

Naturally, ZK provides utilities for one component to access properties of another across ID Spaces; but many developers do not take advantage of these conveniences and continue to employ low level APIs that makes application code complex along with a poor coding experience.

Putting Myth I to the Test

Consider a UI skeleton like the following where the Window and Include components being ID Space owners by default:

<window id="A" >
    <window id="B" >
        <radiogroup id="Z">
            <radio label=”Male”/>
            <radio label=”Female”/>
        </radiogroup>
    </window>
    <include id="C" />
</window>

and our objective is to 

fetch the appropriate page to display based on the selection made in the Radiogroup.

Myth: It’s cumbersome to access components and forward events across ID Spaces.

In myth, the ZUL page would look like this:

<window id="rootWin" use="demyth.zk.DeMyth1Win">
	<window id="innerWin" >
		<radiogroup id="radio" forward="onCheck=${rootWin}.onCheck">
			<radio label="Male"/>
			<radio label="Female"/>
		</radiogroup>
	</window>
	<include id="innerIncld" />
</window>

The corresponding controller class would be:

public class DeMyth1Win extends Window {
	public void onCheck(){
		Radiogroup rg = (Radiogroup)this.getFellow("innerWin").getFellow("radio");
		boolean tf = rg.getSelectedItem().getLabel().equals("Male");
		String s = tf ? "male.zul" : "female.zul";
		Include i = (Include)(this.getSpaceOwner().getFellow("innerIncld"));
		i.setSrc(s);
	}
}

In this version, the onCheck event is forwarded from the RadioGroup to the outermost Window. Hence, getting reference to the RadioGroup or the Include components in the extended Window class meant traversing past ID Spaces using the Component.getFellow method.

Fact: The same goal can be met easily if we follow a little convention

ZUL page “code diff” snippet:

<window id="rootWin" apply="demyth.zk.DeMyth1Ctrl">
		<radiogroup id="radio" >
                .....
The controller:
public class DeMyth1Ctrl extends GenericForwardComposer {

	Radiogroup innerWin$radio;
	Include innerIncld;

	public void onCheck$radio$innerWin(){
		boolean tf = innerWin$radio.getSelectedItem().getLabel().equals("Male");
		String s = tf ? "male.zul" : "female.zul";
		innerIncld.setSrc(s);
	}
}
By following the MVC pattern based on GenericForwardComposer, we have the components wiring and the events forwarding tasks done automatically for us.
This MVC pattern is widely followed, but not many know how easy it is to reference components and events past the ID Space using the $ convention as shown.
The Verdict
ID Space was designed to address any potential ID conflicts between components. This issue becomes prominent when you consider an enterprise grade application where multiple ZUL pages to be meshed is developed by different owners.
In addition, thanks to ID Space, the Window components in male.zul and female.zul which their developers incidentally named “innerWin”, will not conflict with our inner Window component also named “innerWin”.
ZK provides a simple MVC convention for developers to utilize the ID Space mechanism without polluting the code.
Next Up
While we’re going through the sample code, some might ask: what if my controller class cannot extend the GenericForwardComposer given the confines of my application’s implementation?  What’s the difference between all the different composer classes and interfaces? What’s the difference between employing “use” and “apply”?
We’ll look into answering those questions and attempt to bust the myth about “Getting Strayed in The Zoo of ZK Composers” next time.
 
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.