ZK Developer's Reference/UI Composing/ZUML/EL Expressions

Overview

EL expressions are designed to make a ZUML document easy to access objects available in the application, such as application data and parameters.

An EL expressions is an expression enclosed with ${ and }, i.e., the syntax is ${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 attribute allows. For example, the following expressions will be evaluated to boolean and int, respectively.

 <window if="${some > 10}"><!-- boolean -->
   <progressmetter value="${progress}"/><!-- integer -->

If the class does not match, ZK Loader will try to coerce it to the correct one. If failed, an exception is thrown.

Multiple EL expressions could be specified in a single attribute:

<window title="${foo.name}: ${foo.version}">

Example

EL Expression	Result
${1 > (4/2)}	false
${100.0 == 100}	true
${'a' < 'b'}	true
${'hip' gt 'hit'}	false
${1.2E4 + 1.4}	12001.4
${3 div 4}	0.75
${10 mod 4}	2
${empty param.add}	true if the request parameter named add is null or an empty string
${param['mycom.productId']}	The value of the request parameter named mycom.productId

• The example is from JSP Tutorial.
• For more information please refer to Operators and Literals.

Difference from Java

• A string can be enclosed with single quotes or double quotes. In other words, 'abc' and "abc" means the same.
• The empty operator is useful for testing null and empty (string, list and map), such as ${empty param.add}.
• The . operator can be used to access a property of an object (assuming that there is a get method of the same name), or a value of a map, such as ${foo.value.name}.
• The [] operator can be used to access an item of a list or array, a value of a map, and a property of an object (assuming there is a get method of the same name), such as ${ary[5]} and ${wnd['title']}.
• null is returned if the value is not found and the index is out-of-bound.

For more information please refer to Operators and Literals.

Connecting to Java World

EL expressions are evaluated at the server when the page is rendered. Thus, it is allowed to access:

• Components by using its ID
• Variables defined in zscript
• Implicit objects

<window title="EL">
    <textbox id="tb" value="${self.parent.title}"/> <!-- self is an implicit object referring to itself -->
    ${tb.value} <!-- tb is an ID (of textbox) -->
    <button label="Enter" if="${not empty param.edit}"/>
    <zscript>Date now = new Date();</zscript>
    <datebox value="${now}"/> <!-- now is defined in zscript -->
</window>

Furthermore, you could define a variable resolver to associate a name with an object, or map a function to a Java static method as described in the following.

Variable Resolver

If you would like to support many variables, you could implement a variable resolver: a class that implements VariableResolver.

package foo;
public class CustomerResolver implements org.zkoss.xel.VariableResolver {
    public Object resolveVariable(String name) {
        if ("customers".equals(name))
            return Customer.getAll("*");
//     if ("recent".equals(name))
//         return something_else;
        return null; //not a recognized variable
    }
}

Then, you could specify it in a variable-resolver directive, such as:

<?variable-resolver class="foo.CustomerResolve"?>

<listbox>
    <listitem label="${each.name}" forEach="${customers}"/>
</listbox>

System-level Variable Resolver

If you have a variable resolver that shall be used for every page, you could register a system-level variable resolver rather than specifying it on every page.

It could be done by specifying the variable resolver you implemented in WEB-INF/zk.xml as follows. For more information, please refer to ZK Configuration Reference.

<listener>
    <listener-class>foo.MyVariableResolver</listener-class>
</listener>

Then, each time a page is created, an instance of the specified class will be instantiated and registered as if it is specified in the variable-resolver element.

Notice that since a new instance of the variable resolver is created for each page, there is no concurrency issues.

Associate with a Java Method

The collection object could be retrieved by invoking a static method. For example, suppose we have a class and a static method as follows.

package foo;
public class Customer {
    public Collection<Customer> getAll(String condition) {
        //...returns a collection of customers
    }
    public String getName() {
       return _name;
    }
    //...
}

Then, we could retrieve them with the xel-method directive:

<?xel-method prefix="c" name="getAllCustomers" class="foo.Customer"
   signature="java.util.Collection getAll(java.lang.String)"?><!-- Generics not allowed -->
<listbox>
    <listitem label="${each.name}" forEach="${c:getAllCustomers('*')}"/>
</listbox>

Associate with Multiple Java Methods

If you have several static methods, you could declare them in a XML file called taglib, such as

<taglib>
	<function>
		<name>getAllCustomers</name>
		<function-class>foo.Customer</function-class>
		<function-signature>
	java.util.Collection getAll(java.lang.String)
		</function-signature>
		<description>
	Returns a collection of customers.
		</description>
	</function>
	<!-- any number of functions are allowed -->
</taglib>

Then, you could use them by specifying it in a taglib directive.

<?taglib uri="/WEB-INF/tld/my.tld" prefix="my"?>
<listbox>
    <listitem label="${each.name}" forEach="${my:getAllCustomers('*')}"/>
</listbox>

Version History

Version	Date	Content