When a ZK request is asking to render a new page, a new page is created and components that are created duing this request all belong to this page.
If a ZK requst is asking an update, it must have at lease one UUID of a component ( {@link Component#getUuid}. From this UUID, we know which page it belongs and activate it to process the update.
By activation, the system guarantees no concurrent access to pages and components (so you don't need use synchronized for them).
In portal and some environments, a client request (e.g., ServletRequest) might consists of several ZK requests ( {@link org.zkoss.zk.au.AuRequest}). While each ZK request might ask to create an independent page, all these pages are grouped as a desktop, such that they are activated and removed at the same time. Moreover, pages in the same desktop could communicate to eath other (see Inter-page communication).
A session, {@link Session}, might have multiple desktops of pages, {@link Page}, while a page belongs to exactly one session. A page, {@link Page}, might have many components, {@link Component}, while a component belongs to exactly one page.
All components of the same desktop of pages are removed at the same time if a page become 'obsolete'.
During each execution (${link Execution}), exactly one desktop of pages are locked (aka., activated). Though an execution serves a client request (e.g., ServletRequest), a client request might consist of multiple ZK request ( {@link org.zkoss.zk.au.AuRequest}). Each ZK request might target to a different page (of the same desktop).
To do inter-page communication, you could do:
They are the same as handling components from the same page. However, invoking method directly for components from another page has one restriction:
It cannot create component.
@author tomyeh
|
|
|
|
|
|