ID Space"

From Documentation
Line 6: Line 6:
 
The concept of ID space is hence introduced to resolve this issue. An ID space is a subset of components of a desktop. The uniqueness is guaranteed only in the scope of an ID space. Thus, developers could maintain the subset of components separately without the need to worry if there is any conflicts with other subsets.
 
The concept of ID space is hence introduced to resolve this issue. An ID space is a subset of components of a desktop. The uniqueness is guaranteed only in the scope of an ID space. Thus, developers could maintain the subset of components separately without the need to worry if there is any conflicts with other subsets.
  
The simplest form of an ID space is a window (<javadoc>org.zkoss.zul.Window</javadoc> ). All descendant components of a window (including the window itself) forms an independent ID space. Thus, you could use a window as the topmost component to group components, such that developers need only to maintain the uniqueness of each subset separately.
+
The simplest form of an ID space is a window (<javadoc>org.zkoss.zul.Window</javadoc> ). All descendant components of a window (including the window itself) form an independent ID space. Thus, you could use a window as the topmost component to group components. This way developers only need to maintain the uniqueness of each subset separately.
  
 
By and large, any component could form an ID space as long as it implements <javadoc type="interface">org.zkoss.zk.ui.IdSpace</javadoc>, and the component is called the space owner of the ID space it forms. Components in the same ID space are called fellows.
 
By and large, any component could form an ID space as long as it implements <javadoc type="interface">org.zkoss.zk.ui.IdSpace</javadoc>, and the component is called the space owner of the ID space it forms. Components in the same ID space are called fellows.

Revision as of 09:50, 20 July 2011

ID Space

It is common to decompose a visual presentation into several subsets or ZUML pages. For example, you may use a page to display a purchase order, and a modal dialog to enter the payment term. If all components are uniquely identifiable in the same desktop, developers have to maintain the uniqueness of all identifiers for all pages that might create in the same desktop. This step can be tedious, if not impossible, for a sophisticated application.

The concept of ID space is hence introduced to resolve this issue. An ID space is a subset of components of a desktop. The uniqueness is guaranteed only in the scope of an ID space. Thus, developers could maintain the subset of components separately without the need to worry if there is any conflicts with other subsets.

The simplest form of an ID space is a window (Window ). All descendant components of a window (including the window itself) form an independent ID space. Thus, you could use a window as the topmost component to group components. This way developers only need to maintain the uniqueness of each subset separately.

By and large, any component could form an ID space as long as it implements IdSpace, and the component is called the space owner of the ID space it forms. Components in the same ID space are called fellows.

A page also implements IdSpace, so it is also a space owner. Besides window and page, the macro component and the include component (Include) are all space owners.

You could make a standard component as a space owner by extending it to implement IdSpace. There is no method need to implement at all. For example,

public class IdGrid extends Grid implements IdSpace {
   //no method implementation required
}

Tree of ID Space

If an ID space has a child ID space, the components of the child space are not part of the parent ID space, except the space owner of the child ID space. For example, if an ID space, say X, is a descendant of another ID space, say Y, then space X's owner is part of space Y. However, descendants of X is not part of space Y.

For example, the following ZUML page

<?page id="P"?>
<zk>
	<window id="A">
		<hbox id="B">
			<button id="D" />
		</hbox>
		<window id="C">
			<button id="E" />
		</window>
	</window>
	<hbox id="F">
		<button id="G" />
	</hbox>
</zk>

will form ID spaces as follows:

Zk the id space.jpg

As depicted in the figure, there are three spaces: P, A and C. Space P includes P, A, F and G. Space A includes A, B, C and D. Space C includes C and E.

Components in the same ID spaces are called fellows. For example, A, B, C and D are fellows of the same ID space.

getFellow and getSpaceOwner

The owner of an ID space could be retrieved by Component.getSpaceOwner(). Furthermore, any component in an ID space could be retrieved by Component.getFellow(String), if it is assigned with an ID (Component.setId(String)).

Notice that the getFellow method can be invoked against any components in the same ID space, not just the space owner. Similarly, the getSpaceOwner method returns the same object for any components in the same ID space, no matter it is the space owner or not. In the example above, if C calls getSpaceOwner will get C itself, if C calls getSpaceOwnerOfParent will get A.

Composer and Fellow Auto-wiring

With ZK Developer's Reference/MVC, you generally don't need to look up fellows manually. Rather, they could be wired automatically by use of the auto-wiring feature of a composer. For example,

public class MyComposer extends GenericForwardComposer {
    private Textbox input; //will be wired automatically if there is a fellow named input

    public void onOK() {
      Messsagebox.show("You entered " + input.getValue());
    }
    public void onCancel() {
      input.setValue("");
    }
}

Then, you could associate this composer to a component by specifying the apply attribute as shown below.

<window apply="MyComposer">
    <textbox id="input"/>
</window>

Once the ZUML document above is rendered, an instance of MyComposer will be instantiated, and the input member will be initialized with the fellow called input. This process is called "auto-wiring". For more information, please refer to the Wire Variables section.

Path

ZK provides a utility class called Path class to simplify the location of a component among ID spaces. The way of using it is similar to java.io.File. For example,

//Two different ways to get the same component E
Path.getComponent("/A/C/E");//if call Path.getComponent under the same page.
new Path("/A/C", "E").getComponent(); //the same as new Path("/A/C/E").getComponent()

Notice that formal syntax of the path string is "/[/]<space_owner>/[<space_owner>...]/felow" and only last element could be just fellow that is not space owner. For example,

// B and D are fellows in the Id space of A
Path.getComponent("/A/B");  // get B
Path.getComponent("/A/D");  // get D


If a component belongs to another page, then we can retrieve it by starting with the page's ID. Notice that double slashes have to be specified in front of the page's ID.

Path.getComponent("//P/A/C/E");//for page, you have to use // as prefix

Notice that the page's ID can be assigned by use of the page directive as follows.

<?page id="foo"?>
<window/>

UUID

A component has another identifier called UUID (Universal Unique ID). It is assigned automatically when the component is attached to a page. UUID of a component is unique in the whole desktop (if it is attached).

Application developers rarely need to access it.

In general, UUID is independent of ID. UUID is assigned automatically by ZK, while ID is assigned by the application. However, if a component implements RawId, ID will become UUID if the application assigns one. Currently, only components from the XHTML component set implements RawId.

Version History

Last Update : 2011/07/20


Version Date Content
     



Last Update : 2011/07/20

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