Shadow for MVC"

From Documentation
Line 17: Line 17:
 
The shadow element apply will not exist once the output is rendered to client, so developers can't dynamically change the template value. For this purpose, we provide two kinds of Java class for those who have favor of MVC, that is, <javadoc>org.zkoss.zuti.zul.ShadowTemplate</javadoc> and <javadoc>org.zkoss.zuti.zul.CollectionTemplate</javadoc>.  
 
The shadow element apply will not exist once the output is rendered to client, so developers can't dynamically change the template value. For this purpose, we provide two kinds of Java class for those who have favor of MVC, that is, <javadoc>org.zkoss.zuti.zul.ShadowTemplate</javadoc> and <javadoc>org.zkoss.zuti.zul.CollectionTemplate</javadoc>.  
  
They are NOT like normal shadow elements defined in zul but you can only create instances in Java code.
+
They are NOT like normal shadow elements defined in zul but you can only create components in Java code.
  
 
=Use ShadowTemplate=
 
=Use ShadowTemplate=
Line 118: Line 118:
  
 
Although the behavior looks alike between ShadowTemplate and [[ZK Developer's Reference/UI Composing/Macro Component|Macro component]], there exist some differences.
 
Although the behavior looks alike between ShadowTemplate and [[ZK Developer's Reference/UI Composing/Macro Component|Macro component]], there exist some differences.
{| border='1px' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{| border='1px' | width="100%"
 
{| border='1px' | width="100%"
Line 131: Line 124:
 
! Macro Component
 
! Macro Component
 
|-
 
|-
| change parent/host
+
| change host/parent
| 2B
+
| if '''autodrop''' is true, the rendered components will change parent, otherwise, they will still stick with the same parent(or host).
| 2C
+
| no matter it is inline or not, the rendered components will change parent.
 
|-
 
|-
 
| change template/uri
 
| change template/uri
| 3B
+
| if '''autodrop''' is true, the rendered components will be detached, otherwise, they will still stick with the same parent(or host).
| 3C
+
| no matter it is inline or not, the rendered components will be detached.
 
|}
 
|}
  

Revision as of 10:40, 17 September 2015

Introduction

Since ZK 8.0.0, we introduce shadow elements like a boilerplate code to help application developers to compose the html layout with some dynamic data. It is inspired from Shadow DOM to enable better composition of ZK components. For more detail, please check out our Official ZK MVVM Book. Shadow elements can not only be used with MVVM binding but also MVC pattern, but there are some differences. We will give more discussion in the following sections.

In MVC pattern, developers can declare shadow tags in zul files while the behavior is very different without MVVM annotation. For Example,

<apply template="any" />
<template name="any">
    ...
</template>

The shadow element apply will not exist once the output is rendered to client, so developers can't dynamically change the template value. For this purpose, we provide two kinds of Java class for those who have favor of MVC, that is, ShadowTemplate and CollectionTemplate.

They are NOT like normal shadow elements defined in zul but you can only create components in Java code.

Use ShadowTemplate

ShadowTemplate is a utility class to let developers to apply shadow elements in Java class. It has the similar behavior with Apply, for example, developers can specify the template or pass parameters. The difference is that developers must designate a boolean value, called autodrop, to indicate whether to drop those rendered children or not. If true, every time user changed template or detach from the original host, ShadowTemplate will Apply.recreate() or removed the children, otherwise, rendered children will be remained. After instantiating ShadowTemplate instance, developers can trigger ShadowTemplate.apply(Component) to compose the specified template with shadow host passed as parameter. Note that, the passed host should be the same one if autodrop is true, or pass null to detach the original host first.

Example

Assume we have a zul file like this:

<zk>
	<div apply="DemoComposer">
		<div id="host1"></div>
	</div>
	<template name="labels">
		<label value="zul label"/>
		<x:label>xhtml label</x:label>
		<n:span>native span</n:span>
	</template>
</zk>

and in DemoComposer.java

@Wire
Div host1;

public void doAfterCompose(Component comp) throws Exception {
	super.doAfterCompose(comp);
	ShadowTemplate st = new ShadowTemplate(true); //autodrop = true
	st.setTemplate("labels");
	st.apply(host1);
}

In line 6, we instantiate a new ShadowTemplate with autodrop equal to true.

In line 7, assign the template name to st.

In line 8, call apply method and shadow host is Div host1.

Then, we can see template "labels" is rendered and the created component are attached to host1.

If we have a button to change the template,

	@Listen("onClick = #btn")
	public void clickBtn() {
		st.setTemplate("othertemplate");
		st.apply(st.getShadowHost());
	}

Those components rendered before will be detached first, and attach the new ones, note that, developers have to call apply(host) method again.

If developers want to apply to other shadow host, please apply null first and then apply again like this:

st.apply(null);
st.apply(otherHost);

And the rendered components will also be detached.

Another case is autodrop equal to false, and then neither change template nor apply to other host(yes, you can apply different host whatever you want) won't cause rendered components being detached.

Use CollectionTemplate

CollectionTemplate is similar with ShadowTemplate. The difference is that developers have to assign ListModel for iteratively rendering.

Example

We can take use of previous sample code.

<zk>
	<div apply="DemoComposer">
		<div id="host1"></div>
	</div>
	<template name="labels">
		<label value="zul one ${each} "></label>
		<x:label>xhtml one ${each} </x:label>
		<n:span>native one ${each} </n:span>
	</template>
</zk>

The each in line 6, 7, 8 represents each item in ListModel, and in DemoComposer.java

@Wire
Div host1;
ListModel model = new ListModelList(Arrays.asList(new String[]{"1", "2", "3"}));

public void doAfterCompose(Component comp) throws Exception {
	super.doAfterCompose(comp);
	CollectionTemplate ct = new CollectionTemplate(true); //autodrop = true
	ct.setModel(model);
	ct.setTemplate("labels");
	ct.apply(host1);
}

Developers have to prepare a ListModel and assign to the CollectionTemplate instance, then you will see the template is created multiple times. Similarly, either template or model is changed, apply(host) must be triggered to take the effect. The benefit of using CollectionTemplate is that every time the model's content changes the layout will change as well no matter autodrop is true or false.


Note that, both ShadowTemplate and CollectionTemplate don't support set template and template URI at the same time, any one of them should be null or empty string before set another.

Comparison

Although the behavior looks alike between ShadowTemplate and Macro component, there exist some differences.

ShadowTemplate Macro Component
change host/parent if autodrop is true, the rendered components will change parent, otherwise, they will still stick with the same parent(or host). no matter it is inline or not, the rendered components will change parent.
change template/uri if autodrop is true, the rendered components will be detached, otherwise, they will still stick with the same parent(or host). no matter it is inline or not, the rendered components will be detached.

Version History

Last Update : 2015/09/17


Version Date Content
     



Last Update : 2015/09/17

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