Inline Macros"

From Documentation
Line 1: Line 1:
 
{{ZKDevelopersReferencePageHeader}}
 
{{ZKDevelopersReferencePageHeader}}
  
There are two kinds of macro components: inline and regular. By default, regular macros are assumed. To specify inline macros, you have to specify <tt>inline="true"</tt> in the component directive.
+
__TOC__
  
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.
+
An inline macro is a special macro component that behaves like ''inline-expansion''. Unlike a regular macro component, ZK doesn't create a macro component. Rather, it inline-expands the components defined in the macro URI, as if the content of the in-line macro's template is entered directly in the target page.
  
 +
= Declare Inline Macro =
  
use.zul: (target page)
+
To declare an inline macro, we have to specify <tt>inline="true"</tt> in the component directive, while the definition and the use of an inline macro is the same as the regular macro components (i.e., non-inline).
 +
 
 +
For example, suppose we have a macro definition (aka., template) as follows:
  
 
<source lang="xml" >
 
<source lang="xml" >
 +
<!-- username.zul: (macro definition) -->
 +
<row>
 +
Username
 +
<textbox id="${arg.id}" value="${arg.name}"/>
 +
</row>
 +
</source>
 +
 +
 +
We can declare it as an line macro as follows:
 +
 +
<source lang="xml" >
 +
<!-- target page -->
 
<?component name="username" inline="true" macroURI="username.zul"?>
 
<?component name="username" inline="true" macroURI="username.zul"?>
 
<grid>
 
<grid>
Line 17: Line 32:
 
</source>
 
</source>
  
username.zul: (macro definition)
 
 
<source lang="xml" >
 
<row>
 
Username
 
<textbox id="${arg.id}" value="${arg.name}"/>
 
</row>
 
</source>
 
  
Equivalent page:
+
Then, it is equivalent to:
  
 
<source lang="xml" >
 
<source lang="xml" >
Line 39: Line 46:
 
</source>
 
</source>
  
All properties, including <tt>id</tt>, are passed to the inline macro.
+
Notice that all properties, including <tt>id</tt>, are passed to the inline macro too.
  
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.
+
= Regular Macro =
 +
On the other hand, ZK will create a real component (an instance of <javadoc>org.zkoss.zk.ui.HtmlMacroComponent</javadoc>) to represent the regular macro. That is, the macro component is created as the parent of the components that are defined in the macro.
  
 
Inline macros are easier to integrate into sophisticated pages. For example, you ''cannot'' use ''regular'' components in the previous example since <tt>rows</tt> accepts only <tt>row</tt>, not macro components. It is easier to access to all components defined in a macro since they are in the same ID space. It also means the developers must be aware of the implementation to avoid name conflicts.
 
Inline macros are easier to integrate into sophisticated pages. For example, you ''cannot'' use ''regular'' components in the previous example since <tt>rows</tt> accepts only <tt>row</tt>, not macro components. It is easier to access to all components defined in a macro since they are in the same ID space. It also means the developers must be aware of the implementation to avoid name conflicts.
Line 47: Line 55:
 
Regular macros allow the component developers to provide additional API and hide the implementation from the component users. Each regular macro component is an ID space owner, so there is no name conflicts. The users of regular macros usually assume nothing about the implementation. Rather, they access via the well-defined API.
 
Regular macros allow the component developers to provide additional API and hide the implementation from the component users. Each regular macro component is an ID space owner, so there is no name conflicts. The users of regular macros usually assume nothing about the implementation. Rather, they access via the well-defined API.
  
=== An Example ===
+
= An Example =
 
<tt>inline.zul</tt>: (the macro definition)
 
<tt>inline.zul</tt>: (the macro definition)
  

Revision as of 08:54, 8 November 2010

An inline macro is a special macro component that behaves like inline-expansion. Unlike a regular macro component, ZK doesn't create a macro component. Rather, it inline-expands the components defined in the macro URI, as if the content of the in-line macro's template is entered directly in the target page.

Declare Inline Macro

To declare an inline macro, we have to specify inline="true" in the component directive, while the definition and the use of an inline macro is the same as the regular macro components (i.e., non-inline).

For example, suppose we have a macro definition (aka., template) as follows:

<!-- username.zul: (macro definition) -->
<row>
	Username
	<textbox id="${arg.id}" value="${arg.name}"/>
</row>


We can declare it as an line macro as follows:

<!-- target page -->
<?component name="username" inline="true" macroURI="username.zul"?>
<grid>
	<rows>
		<username id="ua" name="John"/>
	</rows>
</grid>


Then, it is equivalent to:

<grid>
	<rows>
		<row>
			Username
			<textbox id="ua" value="John"/>
		</row>
	</rows>
</grid>

Notice that all properties, including id, are passed to the inline macro too.

Regular Macro

On the other hand, ZK will create a real component (an instance of HtmlMacroComponent) to represent the regular macro. That is, the macro component is created as the parent of the components that are defined in the macro.

Inline macros are easier to integrate into sophisticated pages. For example, you cannot use regular components in the previous example since rows accepts only row, not macro components. It is easier to access to all components defined in a macro since they are in the same ID space. It also means the developers must be aware of the implementation to avoid name conflicts.

Regular macros allow the component developers to provide additional API and hide the implementation from the component users. Each regular macro component is an ID space owner, so there is no name conflicts. The users of regular macros usually assume nothing about the implementation. Rather, they access via the well-defined API.

An Example

inline.zul: (the macro definition)

<row>
	<textbox value="${arg.col1}"/>
	<textbox value="${arg.col2}"/>
</row>

useinline.zul: (the target page)

<?component    name="myrow"    macroURI="inline.zul"  inline="true"?>
<window    title="Test of inline macros"    border="normal">
	<zscript><![CDATA[
		import    org.zkoss.util.Pair;
		List  infos = new LinkedList();
		for(int j     = 0;j    <10;++j){
			infos.add(new Pair("A" + j, "B" +j));
		}
	]]>
	</zscript>
	<grid>
		<rows>
			<myrow    col1="${each.x}"    col2="${each.y}"    forEach="${infos}"/>
		</rows>
	</grid>
</window>

Version History

Last Update : 2010/11/8

Version Date Content
     



Last Update : 2010/11/08

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