Table of Contents
SIMPLY RICH
ZKTM
August 2008
Potix Corporation
Revision 107
Copyright © Potix Corporation. All rights reserved.
The material in this document is for information only and is subject to change without notice. While reasonable efforts have been made to assure its accuracy, Potix Corporation assumes no liability resulting from errors or omissions in this document, or from the use of the information contained herein.
Potix Corporation may have patents, patent applications, copyright or other intellectual property rights covering the subject matter of this document. The furnishing of this document does not give you any license to these patents, copyrights or other intellectual property.
Potix Corporation reserves the right to make changes in the product design without reservation and without notification to its users.
The Potix logo and ZK are trademarks of Potix Corporation.
All other product names are trademarks, registered trademarks, or trade names of their respective owners.
Welcome to ZK, the simplest way to make Web applications rich.
The Developer's Reference fully describes properties and methods of components. For concepts, features, refer to the Developer's Guide. For installation, refer to the Quick Start Guide.
Table of Contents
For scripts (aka., zsccript) and EL expressions embedded in a ZUML page, there are a set of implicit objects that enable developers to access components more efficiently.
A map of custom attributes associated with the Web application. It is the same as the getAttributes method in the org.zkoss.zk.ui.WebApp interface.
A Web application is a WAR, and each Web application has an independent set of custom attributes. These attributes are used mainly to communicate among different desktops and sessions.
If the client is based on HTTP, such as a Web browser, this is the same map of attributes stored in javax.servlet.ServletContext. In other words, you could use it communicate with other servlets, such as JSF.
The arg argument passed to the createComponents method in the org.zkoss.zk.ui.Executions class. It might be null, depending on how createComponents is called.
It is the same as self.desktop.execution.arg.
params.put("name", "John");
Executions.createComponents("/my.zul", null, params);
Then, in my.zul,
<window title="${arg.name}">
...
Notice that arg is available only when creating the components for the included page, say my.zul. On the other hand, all events, including onCreate, are processed later. Thus, if you want to access arg in the onCreate's listener, use the getArg method of the org.zkoss.zk.ui.event.CreateEvent class.
A map of custom attributes associated with the component. It is the same as the getAttributes method in the org.zkoss.zk.ui.Component interface.
The current desktop. It is the same as self.desktop.
desktop.getPage("main");
A map of custom attributes associated with the desktop. It is the same as the getAttributes method in the org.zkoss.zk.ui.Desktop interface.
It is mainly used to communicate among pages in the same desktop.
The current item of the collection being iterated, when ZK evaluates an iterative element. An iterative element is an element with the forEach attribute.
<listbox width="100px">
<listitem label="${each}" forEach="${contacts}"/>
</listbox>
The current event. Available for the event listener only.
<textbox onChanging="react(event.value)"/>
<combobox onChanging="autoComplete()"/>
<zscript>
void react(String value) {
...
}
void autoComplete() {
String value = event.getValue();
...
}
</zscript>
The status of an iteration. ZK exposes the information relative to the iteration taking place when evaluating the iterative element.
<zk>
<zscript>
grades = new String[] {"Best", "Better", "Good"};
</zscript>
<listbox width="100px">
<listitem label="${forEachStatus.index}: ${each}" forEach="${grades}"/>
</listbox>
</zk>
Note: forEachStatus.index is absolute with respect to the underlying collection, array or other type. For example, if forEachBegin is 5, then the first value of forEachStatus.index with be 5.
The current page context used to retrieve the request, response, variable resolver and so on.
A map of custom attributes associated with the current page. It is the same as the getAttributes method in the org.zkoss.zk.ui.Page interface.
A map of custom attributes associated with the current execution. It is the same as getAttributes method in the org.zkoss.zk.ui.Execution interface.
The component itself. In other words, it is the closest component, depicted as follows.
<listbox>
<zscript>self.getItems();</zscript><!-- self is listbox -->
<listitem value="ab" label="${self.value}"/><!-- self is listitem -->
<zscript>self.getSelectedIndex();</zscript><!-- self is listbox -->
</listbox>
The session. It is similar to javax.servlet.http.HttpSession[1].
A map of custom attributes associated with the session. It is the same as the getAttributes method in the org.zkoss.zk.ui.Session interface.
If the client is based on HTTP, such as a Web browser, this is the same map of attributes stored in javax.servlet.http.HttpSession. In other words, you could use it communicate with other servlets, such as JSF.
The space owner of this component. It is the same as self.spaceOwner.
The XML processing instructions describe how to process the ZUML page. They will be processed first before processing XML elements.
<?component name="myName" macroURI="/mypath/my.zul" [inline="true|false"] [prop1="value1"] [prop2="value2"]... ?>
<?component name="myName" [class="myPackage.myClass"] [extends="nameOfExistComponent"] [moldName="myMoldName"] [moldURI="/myMoldURI"] [prop1="value1"] [prop2="value2"]... ?>
Defines a new component. There are two formats: by-macro and by-class.
<?component name="myName" macroURI="/mypath/my.zul" [prop1="value1"] [prop2="value2"]... ?>
You could define a new component based on a ZUML page. It is also called the macro component. In other words, once an instance of the new component is created, it creates child components based on the specified ZUML page (the macroURI attribute).
In addition, you could specify the initial properties (such as prop1 in the above example), such that they are always passed to the macro component (thru the arg variable).
The inline attribute specifies whether it is an inline macro (inlinie="true") or a regular macro (default).
An inline macro behaves like inline-expansion. ZK doesn't create a macro component if an inline macro is encountered. Rather, it inline-expands the components defined in the macro URI. In other words, it works as if you type the content of the inline macro directly to the target page.
On the other hand, ZK will create a real component (called a macro component) to represent the regular macro. That is, the macro component is created as the parent of the components that are defined in the macro.
<?component name="myName" [class="myPackage.myClass"] [extends="nameOfExistComponent"] [moldName="myMoldName"] [moldURI="/myMoldURI"] [prop1="value1"] [prop2="value2"]...?>
In addition to defining a component by a ZUML page (aka., a macro component), You could define a new component by implementing a class that implements the org.zkoss.zk.ui.Component interface. Then, use the by-class format to declare such kind of components for a page.
To define a new component, you have to specify at least the class attribute, which is used by ZK to instantiate a new instance of the component.
In addition to defining a new component, you can override properties of existent components by specifying the extends element with the component name that you want to extend from (extendee). In other words, if extends is specified, the previous definition of the extendee is loaded as the default value and then override only properties that are specified in this directive.
For example, assume you want to use MyWindow instead of the default window, org.zkoss.zul.html.Window, for all windows defined in this ZUML page. Then, you can declare it as follows.
<?component name="window" extends="window" class="MyWindow"?> ... <window> ... </window>
It is equivalent to the following codes.
<window use="MyWindow"> ... </window>
In addition, you could specify the properties to initialize. For example, you want to use the style class called blue for all buttons used in this page, then you could:
<?component name="button" extends="button" sclass="blue"?>
Similarly, you could use the following definition to use OK as the default label for all buttons specified in this page.
<?component name="button" extends="button" label="OK"?>
Notice that the properties won't be applied if a component is created manually (by zscript or by Java codes). If you still want them to be applied with the initialial properties, you could invoke the applyProperties method as follows.
<zscript>Button btn = new Button();btn.applyProperties(); //apply the initial properties</zscript>
[Optional]
Used to specify the class to instantiate an instance of such kind of components. Unlike other directives, the class can be defined with zscript.
[Optional]
Specifies the name of the component to extend from (extendee). If specified, the existent definition will be loaded to initialize the new component definition. In other words, it extends the existent definition instead of defining a brand-new one.
[Required if the by-macro format is used][EL is not allowed]
Used with the by-macro format to specify the URI of the ZUML page, which is used as the template to create components.
[Optional][Default: default]
Used with the by-class format to specify the mold name. If moldName is specified, moldURI must be specified, too.
[Optional][EL is allowed]
moldURI="~./zul/in-my-jar.dsp"moldURI="/WEB-INF/in-my-web.dsp"moldURI="/jsp-or-other-servlet"moldURI="class:com.mycompany.myrender"
Used with the by-class format to specify the mold URI. If moldURI is specified but moldName is not specified, the mold name is assumed as default.
In addition to DSP, JSP and any Servlet technologies, you can implement the org.zkoss.zk.util.ComponentRenderer interface, and then specify it in the moldURI attribute by starting with "class:". With this approach, the performance is the best.
[Required]
The component name. If an existent component is defined with the same name, the existent component is completely invisible in this page. If the by-class format is used, the attributes of the existent components are used to initialize the new components and then override with what are defined in this processing instruction.
<?evaluator [name="..."] [class="..."] [import="..."]?>
It specifies how to evaluate XEL expressions.
[optional][Default: none][Case insensitive]
The name of the implementation used to evaluate the XEL expressions. There are two ways to specify the implementation. One is the name attribute. The other is the class attribute.
For example, if you want to use MVEL[2], you can specify the name as follows.
<?evaluator name="mvel"?>
<window id="w" title="MVEL Demo">
${new org.zkoss.zul.Textbox().setParent(w)}
</window>
Here are a list of built-in implementations.
|
Name |
Class / Description |
|---|---|
|
default |
org.zkoss.xel.el.ELFactory The default implementation. It is based on ZK Commons EL (zcommons-el.jar), which is a performance enhancement version of Apache Commons EL. |
|
mvel |
org.zkoss.zkmax.xel.mvel.MVELFactory The implementation based on MVEL, http://mvel.codehaus.org. [available only if zkmax.jar is loaded] |
|
ognl |
org.zkoss.zkmax.xel.ognl.OGNLFactory The implementation based on OGNL, http://www.ognl.org. [available only if zkmax.jar is loaded] |
|
commons-el |
org.zkoss.zkmax.xel.el.ApacheELFactory The implementation that is based on Apache Commons EL, org.apache.commons.el.ExpressionEvaluatorImpl. [available only if zkmax.jar is loaded] |
|
japser-el |
org.zkoss.zkmax.xel.el21.ApacheELFactory The implementation that is based on Apache JSP 2.1 EL, org.apache.el.ExpressionFactoryImpl. [available only if zkmax.jar is loaded] |
You can provide additional implementations by use of the class attribute, as described in the following section. The class must implement the org.zkoss.xel.ExpressionFactory interface. Or, you can specify the following content in metainfo/xel/config.xml.
<config> <xel-config> <evaluator-name>Super</evaluator-name><!-- case insensitive --> <evaluator-class>my.SuperEvaluator</evaluator-class> </xel-config> </config>
[Optional][Default: dependind on how xel-config is specified]
The implementation used to evaluate the XEL expressions. In addition to the name attribute, you can specify the class directly. For example, you can use MVEL by specifying class as follows.
<?evaluator class="org.zkoss.zkmax.xel.mvel.MVELFactory"?>
<window id="w" title="MVEL Demo">
${new org.zkoss.zul.Textbox().setParent(w)}
</window>
[Optiona][Default: what are defined in taglib]
Specifies a list of classes separated with comma to import for evaluating the expression in this page. For example, with MVEL:
<?evaluator class="org.zkoss.zkmax.xel.mvel.MVELFactory"
import="org.zkoss.zul.Datebox,org.zkoss.zul.Combobox"?>
<window id="w" title="MVEL Demo">
${new Datebox().setParent(w)}
</window>
Notice that not all evaluators support the import of classes. For example, all EL-based the evaluators, including the system default one, don't support it. In other words, the import attribute is meaningless to them. Rather, you have to use the taglib directive to import functions.
<?forward uri="..." [if="..."] [unless="..."]?>
It specifies the URI to forward the request to, and the condition to decide whether to forward. If the condition is satisfied or not specified, this page won't be rendered, and the request is, instead, forwarded to the URI specified in the uri attribute.
Notes
Even if the forward is effective (i.e., ZK forwards the request to the specified URI), the initiators specified in the init directives will be called.
The createComponents method of the Execution interface ignores the forward directives. In other words, the forward directives are evaluated only if the ZUML page is loaded directly.
[required][EL expressions allowed]
The URI of the page/servlet to forward to. It may be another ZUML page, a JSP page or any servlet.
If an EL expression is specified and it is evaluated to an empty string, it is considered as no forwarding at all.
[Optional][Default: true][EL expressions allowed]
The condition to forward to the specified URI. If both if and unless are omitted, this page won't be evaluated and ZK always forwards the request to the specified URI.
<?import uri="..."?><?import uri="..." directives="..."?>
It imports the directives, such as component definitions (<?component?>) and initiators (<?init?>), defined in another ZUML page.
A typical use is that you put a set of component definitions in one ZUML page, and then import it in other ZUML pages, such that they share the same set of component definitions, additional to the system default.
<!-- special.zul: Common Definitions --> <?init zscript="/WEB-INF/macros/special.zs"?> <?component name="special" macroURI="/WEB-INF/macros/special.zuml" class="Special"?> <?component name="another" macroURI="/WEB-INF/macros/another.zuml"?>
where the Special class is assumed to be defined in /WEB-INF/macros/special.zs.
Then, other ZUML pages can share the same set of component definitions as follows.
<?import uri="special.zul"?> ... <special/><!-- you can use the component defined in special.zul -->
Notes
Unlike other directives, the import directives must be at the topmost level, i.e., at the the same level as the root element.
The imported directives in the imported page are also imported. For example, if A imports B and B imports C, then A imports both C and B component definitions. If there is a name conflict, A overrides B, while B overrides C.
Once the directives are imported, they won't be changed until the importing page is change, no matter the imported page is changed or not.
[Optional]
If the directives attribute is omitted, only the component and init directives are imported. If you want to import particular directives, you can specify a list of the names of the directives separated by comma. For example,
<?import uri="/template/taglibs.zul" directives="taglib, xel-method"?>
The directives that can be imported include component, init, meta, taglib, variable-resolver, and xel-method. If you want to import them all, specify * to the directives attribute. Notice that meta implies both the meta and link directives.
<?init class="..." [arg0="..."] [arg1="..."] [arg2="..."] [arg3="..."]?>
<?init zscript="..." [arg0="..."] [arg1="..."] [arg2="..."] [arg3="..."]?>
There are two formats. The first format is to specify a class that is used to do the application-specific initialization. The second format is to specify a zscript file to do the application-specific initialization.
The initialization takes place before the page is evaluated and attached to a desktop. Thus, the getDesktop, getId and getTitle method will return null, when initializing. To retrieve the current desktop, you could use the org.zkoss.zk.ui.Execution interface.
You could specify any number of the init directive. The specified class must implement the org.zkoss.zk.ui.util.Initator interface.
<?init class="MyInit1"?> <?init class="MyInit2"?>
[Optional]
A class name that must implement the org.zkoss.zk.ui.util.Initator interface. Unlike the init directive, the class name cannot be the class that is defined in zscript codes.
An instance of the specified class is constructed and its doInit method is called in the Page Initial phase (i.e., before the page is evaluated). The doFinally method is called after the page has been evaluated. The doCatch method is called if an exception occurs during the evaluation.
Thus, you could also use it for cleanup and error handling.
<?link [href="uri"] [name0="value0"] [name1="value1"] [name2="value2"]?><?meta [name0="value0"] [name1="value1"] [name2="value2"]?>
These are so-called header elements in HTML. Currently only HTML-based clients (so-called browsers) support them.
Developers can specify whatever attributes with these header directives. ZK only encodes the URI of the href attribute (by use of the encodeURL method of the Executions class). ZK generates all other attributes directly to the client.
Notice that these header directives are effective only for the main ZUL page. In other words, they are ignored if a page is included by another pages or servlets. Also, they are ignored if the page is a zhtml file.
<?link rel="alternate" type="application/rss+xml" title="RSS feed" href="/rssfeed.php"?><?link rel="shortcut icon" type="image/x-icon" href="/favicon.ico"?> <?link rel="stylesheet" type="text/css" href="~./zul/css/ext.css.dsp"?> <window title="My App"> My content </window>
<?page [id="..."] [title="..."] [style="..."] [cacheable="false|true"] [language="xul/html"] [zscriptLanguage="Java"] [contentType="text/html;charset=UTF-8"] [docType="tag PUBLIC "doctype name" "doctype UI""] [xml="version="1.0" encoding="UTF-8""] [complete="true|false"]?>
It specifies how a page shall be handled. The id and title arguments are the two most important ones.
[Optional][Default: false if Ajax devices, true if XML and MIL devices]
It specifies whether the client can cache the output.
Note: Browsers, such as Firefox and IE, don't handle the cache of DHTML correctly, so it is not safe to specify cacheable with true for Ajax devices.
[Optional][Default: false]
It specifies that this page is a complete page. By complete we mean the page has everything that the client expects. For example, if the client is a HTML browser, then a complete page will generate all necessary HTML tags, such as <html>, <head> and <body>.
By default (false), a ZK page is assumed to be complete if and only if it is not included by other page. In other words, if a ZK page is included by other page, ZK will generate <div> (if the client is a HTML browser) to enclose the output of the (incomplete) ZK page.
If you have a ZK page that contains a complete HTML page and is included by other page, you have to specify true for this option. For example, the includer is nothing but including another page:
//includer.jsp <jsp:include page="includee.zhtml"/>
And, the included page contains a complete HTML page:
<?page complete="true"?> <html xmlns="http://www.zkoss.org/2005/zk/native"><head> <title>My Title</tile> </head> <body> My Content
</body>
</html>
[Optional][Default: depends on the device]
It specifies the content type. If not specified, it depends on the device. For Ajax devices, it is text/html;charset=UTF-8. For XML and MIL devices, it is text/xml;charset=UTF-8.
Application developers rarely need to change it, unless for XML devices.
[Optional][Default: depends on the device]
It specifies the DOCTYPE (the root tag and DTD) that will be generated to the output directly. This directive is mainly used by XML devices. You rarely need to specify the DOCTYPE directive for Ajax or MIL devices. For example,
<?DOCTYPE value="svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd""?>
will cause the output to be generated with the following snippet
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"">
Notice that the <!DOCTYPE...> specified in a ZUML page is processed by ZK Loader. It is not part of the output.
[Optional][Default: generated automatically][EL allowed]
Specifies the identifier of the page, such that we can retrieve it back. If an alphabetical identifier is assigned, it will be available to scripts (aka., zscript) and EL expressions embedded in ZUML pages.
<?page id="${param.id}"?>
[Optional][Default: depending on the extension][Allowed values: xul/html | xhtml]
Specifies the markup language for this page. The markup language determines the default component set. Currently, it supports xul/html and xhtml.
Note: You can place the page directive in any location of a XML document, but the language attribute is meaningful only if the directive is located at the topmost level.
[Optional][Default: width:100%][EL allowed]
Specifies the CSS style used to render the page. If not specified, it depends on the mold. The default mold uses width:100% as the default value.
<?page style="width:100%;height:100%"?>
[Optional][Default: none][EL allowed]
Specifies the page title that will be shown as the title of the browser.
It can be changed dynamically by calling the setTitle method in the org.zkoss.zk.ui.Page interface.
<?page title="${param.title}"?>
[Optional][Default: none]
Specifies the xml processing instruction (i.e., <?xml?>) that will be generated to the output. Currently only XML devices support this option.
For example,
<?page xml="version="1.0" encoding="UTF-8""?>
will generate the following as the first line of the output
<?xml version="1.0" encoding="UTF-8"?>
[Optional][Default: Java][Allowed values: Java | JavaScript | Ruby | Groovy]
Specifies the default scripting language, which is assumed if an zscript element doesn't specify any scripting language explicitly.
<?page zscriptLanguage="JavaScript"?> <zscript> var m = round(box.value); //JavaScript is assumed. </zscript>
If this option is omitted, Java is assumed. Currently ZK supports four different languages: Java, JavaScript, Ruby and Groovy. This option is case insensitive.
Note: Deployers can extend the number of supported scripting languages. Refer to the How to Support More Scripting Language section in the Developer's Guide.
<?root-attributes any-name1="any-value2" any-name2="any-value2"?>
It specifies the additional attributes for the root element of the generated output, which depends on the device types.
Currently, only Ajax devices support this feature and the root element is the html tag. In other words, the attributes specified in the root-attribute directives will become the attributes of the html element of the generated output. For example,
<?root-attributes xmlns:v="urn:schemas-microsoft-com:vml"?>
will cause the HTML output to be generated with the following snippet
<html xmlns="http://www.w3.org/1999/xhtml"xmlns:v="urn:schemas-microsoft-com:vml">
Note: xmlns="http://www.w3.org/1999/xhtml" is always generated.
Note: If the value is specified with an EL expression and it is evaluated to null, the corresponding attribute won't be generated.
<?tablib uri="myURI" prefix="my"?>
This directive is used to load a taglib file, which defines a set of EL functions. The format of a taglib file is the same as that of JSP taglib files.
In the following example, we loads functions defined in the built-in TLD files identified as http://www.zkoss.org/dsp/web/core and then use one of these function called l.
<?taglib uri="http://www.zkoss.org/dsp/web/core" prefix="c"?>
<window title="${c:l('my.title')}">
...
</window>
Tip: ZK searches all TLD files defined in the /metainfo/tld/config.xml file from the classpath. If you want ZK to load your custom TLD files, add them to class path and then specify the following content in the /metainfo/tld/config.xml file. <taglib><taglib-uri>http://your-domain.com/your-path</taglib-uri><taglib-location>/the/path/of/your/tld/file</taglib-location></taglib>
If you to load a TLD file from your Web application, you can specify the path as follows.
<?taglib uri="/WEB-INF/tld/my.tld" prefix="my"?>
[Required][EL is not allowed]
A URL of the taglib file. Unlike other URL and URI, it doesn't interpret ~ or * specially. And, the page and the taglib files it references must be in the same Web application.
<?variable-resolver class="..." [arg0="..."] [arg1="..."] [arg2="..."] [arg3="..."]?>
Specifies the variable resolver that will be used by the zscript interpreter to resolve unknown variables. The specified class must implement the org.zkoss.xel.VariableResolver interface.
You can specify multiple variable resolvers with multiple variable-resolver directives. The later declared one has higher priority.
Notice that the variable-resolver directives are evaluated before the init directives, so the zscript codes referenced by the init directives are affected by the variable resolver.
The following is an example when using ZK with the Spring framework. It resolves Java Beans declared in the Spring framework, such that you access them directly.
<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
[Optional]
A class name that must implement the org.zkoss.xel.VariableResolver interface. Unlike the init directive, the class name cannot be the class that is defined in zscript codes.
[Optional]
You could specify any number of arguments. If specified, arg0 will be passed as the first argument of the constructor, arg1 as the second argument, and so on. Of course, the implementation must have a compatible constructor. If no argument is specified, the default constructor is assumed.
<?xel-method prefix="..." name="..." class="..."signature="..."?>
Specifies a method that shall be imported by the EL evaluator. For example,
<?xel-method prefix="c" name="forName"class="java.lang.Class"signature="java.lang.Class forName(java.lang.String)"?><textbox value="${c:forName('java.util.List')}"/>
ZK elements are special XML elements that are used to control ZUML pages other than creating components.
If there is name conflicts, you could specify the XML name space:
http://www.zkoss.org/2005/zk
<zk:attribute xmlns:zk="http://www.zkoss.org/2005/zk"> ...
<attribute name="myName" [trim="true|false"]>myValue</attribute>
It defines a XML attribute of the enclosing element. The content of the element is the attribute value, while the name attribute specifies the attribute name. It is useful if the value of an attribute is sophisticated, or the attribute is conditional.
<button label="Hi">
<attribute name="onClick">alert("Hi")</attribute>
</button>
It is equivalent to
<button label="Hi" onClick="alert("Hi")"/>
Another example:
<button>
<attribute name="label" if="${param.happy}">Hello World!</attribute>
</button>
[Optional][Default: false]
Specifies whether to omit the leading and trailing whitespaces of the attribute value.
[Optional][Default: true]
Specifies the condition to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to false.
<custom-attributes [scope="component|space|page|desktop|session|application] attr1="value1" [attr2="value2"...]/>
It defines a set of custom attributes of the specified scope. You could specify as many as attributes you want. These attributes can be retrieved by the getAttribute method of the Component interface with the specified scope.
<custom-attributes cd="${param.cd}" a.b="ab"/>
[optional][Default: component]
Specifies the scope to which the custom attributes are associated. If not specified, the component enclosing this element is the default scope to use.
[Optional][Default: none]
Specifies the format of the value. It could be none, list or map.
By default, the value is assigned to the attribute directly after evaluating EL expressions, if any. For example, "apple, ${more}" is evaluated to "apple, orange", if more is "orange", and assigned to the attribute.
If you want to specify a list of values, you can specify the composite attribute with list as follows.
<custom-attributes simple="apple, ${more}" composite="list"/>
Then, it is converted to a list with two elements. The first element is "apple" and the second "orange".
If you want to specify a map of values, you can specify the composite attribute with map as follows.
<custom-attributes simple="juice=apple, flavor=${more}" composite="map"/>
Then, it is converted to a map with two entries. The first entry is ("juice", "apple") and the second ("flavor", "orange").
[Optional][Default: true]
Specifies the condition to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to false.
<variables [local="false|true] var1="value1" [var2="value2"...]/>
It defines a set of variables for the ID space it belongs. It is equivalent to the setVariable method of Component, if it has a parent component, and Page, if it is declared at the page level.
You could specify as many as variables you want. These variables are stored to the namespace of the ID space it belongs. Thus, they can be accessible by the interpreters and EL expressions.
<variables cd="${param.cd}" less="more"/>
[optional][Default: false]
Specifies whether to store the variable always at the current ID space. By default, it is false. It means ZK will check the existence of any variable with the same name by looking up the current ID space, the parent ID space, and parent's parent, and so on. If found, the variable's value is replaced with the value specified here. If not, a local variable is created. If true is specified, it doesn't look up any parent ID space.
[Optional][Default: none]
Specifies the format of the value. It could be none, list or map.
By default, the value is assigned to the variable directly after evaluating EL expressions, if any. For example, "apple, ${more}" is evaluated to "apple, orange", if more is "orange", and assigned to the variable.
If you want to specify a list of values, you can specify the composite attribute with list as follows.
<variables simple="apple, ${more}" composite="list"/>
Then, it is converted to a list with two elements. The first element is "apple" and the second "orange".
If you want to specify a map of values, you can specify the composite attribute with map as follows.
<variables simple="juice=apple, flavor=${more}" composite="map"/>
Then, it is converted to a map with two entries. The first entry is ("juice", "apple") and the second ("flavor", "orange").
[Optional][Default: true]
Specifies the condition to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to false.
<zk>...</zk>
It is a special element used to aggregate other components. Unlike a real component (say, hbox or div), it is not part of the component tree being created. In other words, it doesn't represent any component. For example,
<window><zk><textbox/><textbox/></zk></window>
is equivalent to
<window> <textbox/><textbox/> </window>
The main use is to represent multiple root elements in XML format.
<?page title="Multiple Root"?>
<zk>
<window title="First">
...
</window>
<window title="Second" if="${param.secondRequired}">
...
</window>
</zk>
The other use is to iterate over versatile components.
<window>
<zk forEach="${mycols}">
<textbox if="${each.useText}"/>
<datebox if="${each.useDate}"/>
<combobox if="${each.useCombo}"/>
</zk>
</window>
[Optional][Default: true]
Specifies the condition to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to false.
[Optional][Default: false]
Specifies the condition not to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to true.
[Optional][Default: ignored]
It specifies a collection of objects, such that the zk element will be evaluated repeatedly against each object in the collection. If not specified or empty, this attribute is ignored. If non-collection object is specified, it is evaluated only once as if a single-element collection is specified.
[Optional][Default: 0]
It is used with the forEach attribute to specify the starting offset when iterating a collection of objects. If not specified, it iterates from the first element, i.e., 0 is assumed.
[Optional][Default: 0]
It is used with the forEach attribute to specify the index (starting from 0) that the iteration shall begin at. If not specified, the iteration begins at the first element, i.e., 0 is assumed.
If forEachBegin is greater than or equals to the number of elements, no iteration is performed.
[Optional][Default: the last element]
It is used with the forEach attribute to specify the index (starting from 0) the iteration shall ends at (inclusive). If not specified, the iterations ends at the last element.
If forEachEnd is greater than or equals to the number of elements, the iteration ends at the last element.
<zscript [language="Java|JavaScript|Ruby|Groovy"]>Scripting codes</zscript><zscript src="uri" [language="Java|JavaScript|Ruby|Groovy"]/>
It defines a piece of scripting codes that will be interpreted when the page is evaluated. The language of the scripting codes is, by default, Java. You can select a different language by use the language attribute[3].
The zscript element has two formats as shown above. The first format is used to embed the scripting codes directly in the page. The second format is used to reference an external file that contains the scripting codes.
<zscript>
alert("Hi");
</zscript>
<zscript src="/codes/my.bs"/>
Like other ZK elements, it is not a component but a special XML element.
[Optional][Default: none]
Specifies the URI of the file containing the scripting codes. If specified, the scripting codes will be loaded as if they are embedded directly.
Note: the file shall contain the source codes in the selected scripting language. The encoding must be UTF-8. Don't specify a class file (aka. byte codes).
Like other URL and URI, it has several characteristics as follows.
It is relative to the servlet context path (aka., the getContextPath method from the javax.servlet.http.HttpServletRequest interface). In other words, ZK will prefix it with the servlet context automatically.
It resolves "~" to other Web application (aka., different ServletContext). Notice that Web server administrator might disable Web applications from peeking other's content[4].
It accepts "*" for loading browser and Locale dependent style sheet.
The algorithm to resolve "*" is as follows.
If there is one "*" is specified in an URL or URI such as /my*.css, then "*" will be replaced with a proper Locale depending on the preferences of user's browser.For example, user's preferences is de_DE, then ZK searches /my_de_DE.css, /my_de.css, and /my.css one-by-one from your Web site, until any of them is found. If none of them is found, /my.css is still used.
If two or more "*" are specified in an URL or URI such as "/my*/lang*.css", then the first "*" will be replaced with "ie" for Internet Explorer and "moz" for other browsers[5]. If the last "*" will be replaced with a proper Locale as described above.
All other "*" are ignored.
[Optional][Default: the page's default scripting language][Allowed Values: Java | JavaScript | Ruby | Groovy]
It specifies the scripting language which the scripting codes are written in.
[Optional][Default: false]
Specifies whether to defer the evaluation of this element until the first non-deferred zscript codes of the same language has to be evaluated. It is used to defer the loading of the interpreter and then speed up the loading of a ZUML page. For example, if all zscript elements are deferred, they are evaluated only when the first event listened by a handler implemented in zscript is received.
Refer to the How to Defer the Evaluation section in the Developer's Guide.
[Optional][Default: true]
Specifies the condition to evaluate this element. This element is ignored if the value specified to this attribute is evaluated to false.
ZK attributes are used to control the associated element, other than initializing the data member.
apply="a-class-name"apply="class1, class2,..."apply="${EL_returns_a_class_or_a_collection_of_classes}"apply="${EL_returns_an_instance_or_a_collection_of_Composer_instances}"
It specifies a class, a collection of classes that are used to initialize the component. The class must implement the org.zkoss.zk.util.Composer interface. And then, you can do the initialization in the doAfterCompose method, since it is called after the component and all its children are instantiated.
<window apply="MyComposer"/>
In addition, you specify a Composer instance, or a collection of Composer instances by use of EL expressions.
Note: the EL expressions are, if specified, evaluated before the component is instantiated. So you cannot reference to the component. Moreover, the self variable references to the parent component, if any, or the current page, if it is the root component, in the EL expressions specified in this attribute.
If you want more control such as handling the exception, you can also implement the org.zkoss.zk.util.ComposerExt interface.
forEach="${an-EL-expr}"forEach="an-value, ${an-EL-expr}"
There are two formats. First, you specify a value without comma. The value is usually a collection of objects, such that the associated element will be evaluated repeatedly against each object in the collection. If not specified or empty, this attribute is ignored. If non-collection object is specified, it is evaluated only once as if a single-element collection is specified.
Second, you can specify a list of values by separating them with comma. Then, the associated element will be evaluated repeatedly against each value in the list.
For each iteration, two variables, each and forEachStatus, are assigned automatically to let developers control how to evaluate the associated element.
<hbox>
<zscript>
classes = new String[] {"College", "Graduate"};
grades = new Object[] {
new String[] {"Best", "Better"}, new String[] {"A++", "A+", "A"}
};
</zscript>
<listbox width="200px" forEach="${classes}">
<listhead>
<listheader label="${each}"/>
</listhead>
<listitem label="${forEachStatus.previous.each}: ${each}"
forEach="${grades[forEachStatus.index]}"/>
</listbox>
</hbox>
forEachBegin="${an-EL-expr}"
It is used with the forEach attribute to specify the index (starting from 0) that the iteration shall begin at. If not specified, the iteration begins at the first element, i.e., 0 is assumed.
If forEachBegin is greater than or equals to the number of elements, no iteration is performed.
Note: forEachStatus.index always starts from 0, no matter what forEachBegin is.
forEachEnd="${an-EL-expr}"
It is used with the forEach attribute to specify the index (starting from 0) the iteration shall ends at (inclusive). If not specified, the iterations ends at the last element.
If forEachEnd is greater than or equals to the number of elements, the iteration ends at the last element.
forward="orginalEvent=targetId1/targetId2.targetEvent"forward="orginalEvent=targetId1/targetId2.targetEvent(eventData)"forward="originalEvent=${el-target}.targetEvent(${el-eventdata})"forward="targetEvent"
It is used to forward an event, that is targeting a specific component, to another component in another event name. It is called the forward condition.
The forward event is an instance of the org.zkoss.zk.ui.event.ForwardEvent class. you can invoke the getOrigin method to retrieve the original event.
The original event is optional. If it is omitted, onClick is assumed. Similarly, the target ID is also optional. If omitted, the space owner is assumed.
The data specified in the parenthesis is the application-specific data, which can be retrieved by calling the getData method.
<button forward="onCancel(abort)"/><!-- "abort" is passed -->
<button forward="onPrint(${inf})"/><!-- the object returned by ${inf} is passed -->
If you want to forward several events, you can specify these conditions in the forward attribute by separating them with the comma (,):
<textbox forward="onChanging=onUpdating, onChange=some.onUpdate"/>
The target component and the event data can be specified in EL expressions, while the event names cannot.
fulfill="event-name"fulfill="target-id.event-name"fulfill="id1/id2/id3.event-name"fulfill="${el-expr}.event-name"
It is used to specify when to create the child components. By default (i.e., fulfill is not specified), the child components are created right after its parent component, at the time the ZUML page is loaded.
If you want to defer the creation of the child components, you can specify the condition with the fulfill attribute. The condition consists of the event name and, optionally, the target component's identifier or path. It means that the child elements won't be processed, until the event is received by, if specified, the target component. If the identifier is omitted, the same component is assumed.
If an EL expression is specified, it must return a component, an identifier or a path.
if="${an-EL-expr}"
It specified the condition to evaluate the associated element. In other words, the associated element and all its child elements are ignored, if the condition is evaluated to false.
unless="${an-EL-expr}"
It specified the condition not to evaluate the associated element. In other words, the associated element and all its child elements are ignored, if the condition is evaluated to true.
[1] ZK session actually encapsulates the HTTP session to make ZK applications independent of HTTP.
[2] MVEL is a powerful expression language. Refer to http://mvel.codehaus.org/ for more information.
[3] Furthermore, you can use the page directive to change the default scripting language other than Java.
[4] Refer to the getContext meth from the javax.servlet.ServletContext interface.
[5] In the future editions, we will use different codes for browsers other than IE and FF.
This chapter describes the details about applying EL expressions to ZUML pages.
EL expressions use the syntax ${expr}. For example,
<element attr1=”${bean.property}”.../>
${map[entry]}
<another-element>${3+counter} is ${empty map}</another-element>
When an EL expression is used as an attribute value, it could return any kind of objects as long as the component accepts it. For example, the following expression will be evaluated to a Boolean object.
<window if="${some > 10}">
EL expressions can be used
In static text
In any attribute's value including XML elements and XML processing instructions.
Like using EL expressions in JSP pages, you could use most of standard implicit objects in ZUML pages.
A map of page-scoped attributes (String, Object).
Notice: the page concept is a bit different from JSP because a ZK page exists across requests.
All variables defined in ZK scripts (aka., zscript) are available for the EL expressions. Thus, all implicit objects described in the previous chapter are also the implicit objects for the EL expressions. You are free to use self, event, componentScope and others. Refer to the Implict Objects section in the ZK User Interface Markup Language chapter.
Table of Contents
All XUL components are packed in the org.zkoss.zul.html package.
The XML name space is http://www.zkoss.org/2005/zul
The extensions include xul and zul.
The component names are case-sensitive. They are all in lower-cases.
A skeletal implementation of Component. Though it is OK to implement Component from scratch, this class simplifies some of the chores.
|
Name |
Description |
Return Data Type |
|---|---|---|
|
|
Associates an annotation to this component. |
|
|
|
Adds an annotation to the specified proeprty of this component. |
|
|
|
Adds an event handler. |
|
|
|
Adds an event listener to specified event for this component. |
|
|
|
Add a map of annotations which is shared by other components. |
|
|
|
Adds a map of event handlers which is shared by other components. |
|
|
|
Appends a child to the end of all children. |
|
|
|
Initializes the properties (aka. members) and custom-attributes based on what are defined in the component definition. |
|
|
|
Clones the component. |
|
|
|
Returns whether the specified variable is defined. |
|
|
|
Detaches this component such that it won't belong to any page. |
|
|
|
Returns a read-only list of the name (String) of properties that are associated at least one annotation (never null). |
|
|
|
Returns a read-only list of the names (String) of the properties that are associated with the specified annotation (never null). |
|
|
|
Returns the annotation associated with the component, or null if not available. |
|
|
|
Returns the annotation associated with the definition of the specified property, or null if not available. |
|
|
|
Returns a read-only collection of all annotations associated with this component (never null). |
|
|
|
Returns a read-only collection of all annotations associated with the specified property (never null). |
|
|
|
Returns the custom attribute associated with this component, i.e., Component.COMPONENT_SCOPE. |
|
|
|
Returns the value of the specified custom attribute in the specified scope, or null if not defined. |
|
|
|
Returns all custom attributes associated with this component, i.e., Component.COMPONENT_SCOPE. |
|
|
|
Returns all custom attributes of the specified scope. |
|
|
|
Returns a live list of children. |
|
|
|
Returns the component definition of this component (never null). |
|
|
|
Returns the desktop of this component, or null if this component doesn't belong to any desktop. |
|
|
|
Returns the event handler of the specified name, or null if not found. |
|
|
|
Returns the extra controls that tell ZK how to handle this component specially. |
|
|
|
Returns a component of the specified ID in the same ID space. |
|
|
|
Returns a component of the specified ID in the same ID space, or null if not found. |
|
|
|
Returns an iterator for iterating listener for the specified event. |
|
|
|
Returns the namespace to store variables and functions belonging to the ID space of this component. |
|
|
|
Returns the page that this component belongs to, or null if it doesn't belong to any page. |
|
|
|
Returns the parent component, or null if this is the root component. |
|
|
|
Default: null (no propagation at all). |
|
|
|
Returns the root of the specified component. |
|
|
|
Returns the owner of the ID space that this component belongs to. |
|
|
|
Returns UUID (universal unique ID) which is unquie in the whole session. |
|
|
|
Returns the value of a variable defined in the namespace, or null if not defined or the value is null. |
|
|
|
Inserts a child before the reference child. |
|
|
|
Invalidates this component by setting the dirty flag such that it will be redraw the whole content later. |
|
|
|
Default: return true (allows to have children). |
|
|
|
Returns whether the event listener is available. |
|
|
|
Default: does nothing. |
|
|
|
Default: does nothing. |
|
|
|
Called when a new-created child is drawn. |
|
|
|
Notifies that an WrongValueException instance is thrown, and WrongValueException.getComponent() is this component. |
|
|
|
Includes the page returned by getMoldURI() and set the self attribute to be this component. |
|
|
|
Removes the custom attribute associated with this component, i.e., Component.COMPONENT_SCOPE. |
|
|
|
Removes the specified custom attribute in the specified scope. |
|
|
|
Removes a child. |
|
|
|
Removes an event listener. |
|
|
|
Causes a response (aka., a command) to be se |