Life Cycle Listener"
m |
m (→Interfaces) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 17: | Line 17: | ||
|- | |- | ||
| Application Cleanup | | Application Cleanup | ||
| − | | | + | | <javadoc type="interface">org.zkoss.zk.ui.util.WebAppCleanup</javadoc> |
|- | |- | ||
| Session Init | | Session Init | ||
| Line 23: | Line 23: | ||
|- | |- | ||
| Session Cleanup | | Session Cleanup | ||
| − | | | + | | <javadoc type="interface">org.zkoss.zk.ui.util.SessionCleanup</javadoc> |
|- | |- | ||
| Desktop Init | | Desktop Init | ||
| Line 29: | Line 29: | ||
|- | |- | ||
| Desktop Cleanup | | Desktop Cleanup | ||
| − | | | + | | <javadoc type="interface">org.zkoss.zk.ui.util.DesktopCleanup</javadoc> |
|- | |- | ||
| Execution Init | | Execution Init | ||
| Line 35: | Line 35: | ||
|- | |- | ||
| Execution Cleanup | | Execution Cleanup | ||
| − | | | + | | <javadoc type="interface">org.zkoss.zk.ui.util.ExecutionCleanup</javadoc> |
|} | |} | ||
| + | |||
| + | Notice that ZK will instantiate an object from the class you registered for each callback. For example, an object is instantiated to invoke <javadoc method="init(org.zkoss.zk.ui.Desktop, java.lnag.Object)" type="interface">org.zkoss.zk.ui.util.DesktopInit</javadoc>, and another object instantiated to invoke <javadoc method="cleanup(org.zkoss.zk.ui.Desktop)" type="interface">org.zkoss.zk.ui.util.DesktopCleanup</javadoc>, even if you register a class that implements both <javadoc type="interface">org.zkoss.zk.ui.util.DesktopInit</javadoc> and <javadoc type="interface">org.zkoss.zk.ui.util.DesktopCleanup</javadoc>. | ||
| + | |||
| + | If you have something that is initialized in the init callback and have to clean it up in the cleanup callback, you cannot store it as a data member. Rather, you have to maintain it by yourself, such as storing it in the desktop's attributes (<javadoc type="interface" method="setAttribute(java.lang.String, java.lang.Object)">org.zkoss.zk.ui.Desktop</javadoc>), session's attributes or application's attributes. | ||
=Registration= | =Registration= | ||
Revision as of 07:43, 2 December 2010
You could have some custom initialization and cleanup when an application, a session, a desktop or an execution is instantiated or about to being destroyed.
There are two steps:
- Implements the corresponding interface. For example, WebAppInit for application's initialization
- Register it in WEB-INF/zk.xml, or in Java.
Interfaces
| Task | Interface |
|---|---|
| Application Init | WebAppInit |
| Application Cleanup | WebAppCleanup |
| Session Init | SessionInit |
| Session Cleanup | SessionCleanup |
| Desktop Init | DesktopInit |
| Desktop Cleanup | DesktopCleanup |
| Execution Init | ExecutionInit |
| Execution Cleanup | ExecutionCleanup |
Notice that ZK will instantiate an object from the class you registered for each callback. For example, an object is instantiated to invoke DesktopInit.init(Desktop, Object), and another object instantiated to invoke DesktopCleanup.cleanup(Desktop), even if you register a class that implements both DesktopInit and DesktopCleanup.
If you have something that is initialized in the init callback and have to clean it up in the cleanup callback, you cannot store it as a data member. Rather, you have to maintain it by yourself, such as storing it in the desktop's attributes (Desktop.setAttribute(String, Object)), session's attributes or application's attributes.
Registration
The registration in WEB-INF/zk.xml is the same, no matter what interface you implement:
<listener>
<listener-class>my.MyImplementation</listener-class>
</listener>
The registration in Java is done by Configuration.addListener(Class).
webapp.getConfiguration().addListener(my.MyImplementation.class);
Version History
| Version | Date | Content |
|---|---|---|