Wire Variables"

From Documentation
m
Line 12: Line 12:
 
#Then, it searches any field to see if it matches any fellow, any variable,... the same as the above.
 
#Then, it searches any field to see if it matches any fellow, any variable,... the same as the above.
  
=Wire Components=
+
=Wire Spring-managed Beans=
==CSS3 Selectors==
 
=Wire Variables defined Variable Resolver=
 
==Wire Spring-managed Beans==
 
 
Because the variable resolver will be checked when wiring a variable, you could wire a managed bean by declaring a built-in variable resolved called <javadoc>org.zkoss.zkplus.spring.DelegatingVariableResolver</javadoc>.
 
Because the variable resolver will be checked when wiring a variable, you could wire a managed bean by declaring a built-in variable resolved called <javadoc>org.zkoss.zkplus.spring.DelegatingVariableResolver</javadoc>.
  
Line 31: Line 28:
  
 
<source lang="java" high="2">
 
<source lang="java" high="2">
public class PasswordSetter extends SelectorComposer {
+
public class PasswordSetter extends GenericFowardComposer {
    @WireXel
+
     private User user; //wired automatically if user is a spring-managed bean
     private User user;
 
    @Wire("#password")
 
 
     private Textbox password; //wired automatically if there is a textbox named password
 
     private Textbox password; //wired automatically if there is a textbox named password
  
    @Listen("onClick=#submit")
+
     public void onClick@submit() {
     public void submit() {
 
 
         user.setPassword(password.getValue());
 
         user.setPassword(password.getValue());
 
     }
 
     }
Line 44: Line 38:
 
</source>
 
</source>
  
=Wire Variables defined in zscript=
+
=zscript and Variable Resolver=
 +
 
 +
By default, variables defined in both zscript and variable resolvers will be checked<ref>It will be default to '''false''' in ZK 6 for better performance.</ref>. There might be some performance penalty if you have too much zscript code, or your variable resolver is too slow.
 +
 
 +
You could turn them off by passing false to the second and third argument of <javadoc method="GenericForwardComposer(char, boolean, boolean)">org.zkoss.zk.ui.util.GenericForwardComposer</javadoc>:
 +
 
 +
<source lang="java">
 +
public class MyComposer extends GenericForwardComposer {
 +
    public MyComposer() {
 +
        super('$', false, false);
 +
    }
 +
}
 +
</source>
 +
 
 +
Notice if you disable the wiring of EL variables (i.e., variables defined in a variable resolver), you can't wire the Spring-managed beans as described in the previous section.
 +
 
 +
<blockquote>
 +
----
 +
<references/>
 +
</blockquote>
 +
 
 +
=ID Space=
 +
 
 +
For components that are inside of another ID space, you could use <code>id1$id2$id3</code> to access it. More precisely, it will cause GenericForwardComposer to look for <code>id1</code> in the same ID space as the applied component, and then look for, if found and it is another ID space, <code>id2</code>, and so on. For example, you could find the textbox by <code>inner$input</code>.
 +
 
 +
<source lang="xml">
 +
<window apply="foo.MyComposer">
 +
  <window id="inner">
 +
        <textbox id="input"/>
 +
...
 +
</source>
 +
 
 +
Here is another example: suppose have two ZUL files:
 +
 
 +
{|
 +
!width="350px"|'''Main file'''
 +
!width="350px"|'''Included file - includeme.zul'''
 +
|-
 +
|
 +
<source lang="xml">
 +
<window id="mywindow" apply="MyComposer">
 +
    <include id="i" src="includeme.zul" />
 +
</window>
 +
</source>
 +
|
 +
<source lang="xml">
 +
  <textbox id="username" />
 +
</source>
 +
|}
 +
 
 +
To access the textbox "username" from "MyComposer", you could specify:
 +
 
 +
<source lang="java">
 +
public class MyComposer extends GenericAutowireComposer {
 +
    Textbox i$username;
 +
    ...
 +
}
 +
</source>
  
 
=Version History=
 
=Version History=

Revision as of 09:04, 7 December 2011

Wiring Sequence

GenericForwardComposer will wire members defined in the composer. Here is the sequence:

  1. It searches any setters if its name matches any of the following
    1. Any fellow with the same name (Component.getFellow(String))
    2. Any variable defined in Page.addVariableResolver(VariableResolver) with the same name
    3. Any variable defined in zscript with the same name
    4. Any implicit object with the same name
  2. Then, it searches any field to see if it matches any fellow, any variable,... the same as the above.

Wire Spring-managed Beans

Because the variable resolver will be checked when wiring a variable, you could wire a managed bean by declaring a built-in variable resolved called DelegatingVariableResolver.

<?variable-resolver class="org.zkoss.zkplus.spring.DelegatingVariableResolver"?>
<window apply="foo.MyComposer">
...
    <textbox id="password"/>
...
    <button id="submit" label="Change"/>
</window>

Then, if a data member's name matches a Spring-managed bean, it will be wired automatically too. For example,

public class PasswordSetter extends GenericFowardComposer {
    private User user; //wired automatically if user is a spring-managed bean
    private Textbox password; //wired automatically if there is a textbox named password

    public void onClick@submit() {
        user.setPassword(password.getValue());
    }
}

zscript and Variable Resolver

By default, variables defined in both zscript and variable resolvers will be checked[1]. There might be some performance penalty if you have too much zscript code, or your variable resolver is too slow.

You could turn them off by passing false to the second and third argument of GenericForwardComposer.GenericForwardComposer(char, boolean, boolean):

public class MyComposer extends GenericForwardComposer {
    public MyComposer() {
        super('$', false, false);
    }
}

Notice if you disable the wiring of EL variables (i.e., variables defined in a variable resolver), you can't wire the Spring-managed beans as described in the previous section.


  1. It will be default to false in ZK 6 for better performance.

ID Space

For components that are inside of another ID space, you could use id1$id2$id3 to access it. More precisely, it will cause GenericForwardComposer to look for id1 in the same ID space as the applied component, and then look for, if found and it is another ID space, id2, and so on. For example, you could find the textbox by inner$input.

<window apply="foo.MyComposer">
   <window id="inner">
        <textbox id="input"/>
...

Here is another example: suppose have two ZUL files:

Main file Included file - includeme.zul
<window id="mywindow" apply="MyComposer">
    <include id="i" src="includeme.zul" />
</window>
   <textbox id="username" />

To access the textbox "username" from "MyComposer", you could specify:

public class MyComposer extends GenericAutowireComposer {
    Textbox i$username;
    ...
}

Version History

Last Update : 2011/12/07


Version Date Content
     



Last Update : 2011/12/07

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