From Documentation

(Difference between revisions)
Jump to: navigation, search
(Values of Stubonly: true, false and inherit)
(Limitation of Stub Components)
Line 31: Line 31:
= Limitation of Stub Components =
= Limitation of Stub Components =
-
When a component is stub only, it will be replaced with a special component called a stub component (<javadoc>org.zkoss.zk.ui.StubComponent</javadoc>). Furthermore, stub components might be merged to minimize the memory further. The application shall not access the component again if it is specified as stub only.
+
When a component is stub only, it will be replaced with a special component called a stub component (<javadoc>org.zkoss.zk.ui.StubComponent</javadoc>) after rendered. In additions, adjacent stub components might be merged to minimize the memory further. Thus, the application shall not access the component again at the server, if it is specified as stub only.
== Invalidation ==
== Invalidation ==
-
While a stub component cannot be invalidated directly, it is safe to invalidate its parent. ZK will rerender all non-stub components and retain the states of stub components at the client. For example, in the following example it is safe to click the <tt>invalidate</tt> button. For end user's point of view, there is no difference if <tt>stubonly</tt> is specified or not.
+
While a stub component cannot be invalidated directly, it is safe to invalidate its parent. ZK will rerender all non-stub components and retain the states of stub components at the client. For example, in the following snippet, it is safe to click the <tt>invalidate</tt> button. For end user's point of view, there is no difference whether <tt>stubonly</tt> is specified or not.
<source lang="xml">
<source lang="xml">

Revision as of 10:55, 9 August 2010





Contents


Overview

[since 5.0.4][ZK EE]

It is common that the states of some components are not required to maintain at the server. A typical example is that an application might use some components, such as hbox, for layout and won't access it again after rendered. To minimize the memory footprint, ZK supports a special property called stubonly (Component.setStubonly(String)). Once specified with true, its states won't be maintained at the server (and all states are maintained at the client). For example,

<hbox stubonly="true">
</hbox>

Values of Stubonly: true, false and inherit

The default value of the stubonly property is inherit. It means the value is the same as its parent's, if any, or false, if no parent at all. Thus, if a component's stubonly is specified with true, all its descendants are stub-only too, unless false is specified explicitly. For example, in the following snippet, only textbox is not stub-only, while hbox, splitter, listbox, listitem and labels are all stub-only.

<hbox stubonly="true">
  a stub-only label
  <textbox stubonly="false"/>
  <splitter/>
  <listbox>
    <listitem label="also stubonly"/>
  </listbox>
</hbox>

Limitation of Stub Components

When a component is stub only, it will be replaced with a special component called a stub component (StubComponent) after rendered. In additions, adjacent stub components might be merged to minimize the memory further. Thus, the application shall not access the component again at the server, if it is specified as stub only.

Invalidation

While a stub component cannot be invalidated directly, it is safe to invalidate its parent. ZK will rerender all non-stub components and retain the states of stub components at the client. For example, in the following snippet, it is safe to click the invalidate button. For end user's point of view, there is no difference whether stubonly is specified or not.

 <window>
  <button label="self.parent.invalidate()"/>
  <vbox stubonly="true">
  stubonly <textbox/>
  </vbox>
</window>

Event Handling

Client-side Programming



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



link title