Template Examples - Locker"
Robertwenzel (talk | contribs) m (→How to use it) |
Robertwenzel (talk | contribs) m (→What we want) |
||
| Line 10: | Line 10: | ||
= What we want = | = What we want = | ||
| − | + | Our goal is to avoid multiple users from editing the same resource simultaneously we need the following functionalities. | |
# '''lock / unlock''' a resource | # '''lock / unlock''' a resource | ||
| Line 18: | Line 18: | ||
# '''react''' to LockEvents and update the UI | # '''react''' to LockEvents and update the UI | ||
#:immediately indicate availability/ownership/unavailability of a resource to the user | #:immediately indicate availability/ownership/unavailability of a resource to the user | ||
| + | |||
| + | First we need a way to indicate our intention that we want to edit a resource and obtain a lock and vice versa return the lock when we are done editing. | ||
| + | This is only useful if others users are aware of that condition so they don't attempt concurrent editing (and potentially losing data or producing inconsistent merged results) - means we need to observe the current lock status and finally react in the UI. | ||
| + | e.g. by changing labels, styles, disabling/hiding/removing/adding appropriate controls. | ||
= How it works = | = How it works = | ||
Revision as of 08:23, 29 December 2017
Robert Wenzel, Engineer, Potix Corporation
January XX, 2018
ZK 8.5
Introduction
What we want
Our goal is to avoid multiple users from editing the same resource simultaneously we need the following functionalities.
- lock / unlock a resource
- e.g. obtain and release exclusive access to edit a specific objects properties
- observe a resource for owner changes (LockEvents)
- it should be possible to observe the same resource with multiple concurrent users
- react to LockEvents and update the UI
- immediately indicate availability/ownership/unavailability of a resource to the user
First we need a way to indicate our intention that we want to edit a resource and obtain a lock and vice versa return the lock when we are done editing. This is only useful if others users are aware of that condition so they don't attempt concurrent editing (and potentially losing data or producing inconsistent merged results) - means we need to observe the current lock status and finally react in the UI. e.g. by changing labels, styles, disabling/hiding/removing/adding appropriate controls.
How it works
Summary
Example Sources
The code examples are available on github in the zk-template-examples repository
- zul files: https://github.com/zkoss-demo/zk-template-examples/tree/master/src/main/webapp/locker
- java classes: https://github.com/zkoss-demo/zk-template-examples/tree/master/src/main/java/zk/example/template/locker
Running the Example
Clone the repo
git clone git@github.com:zkoss-demo/zk-template-examples.git
The example war file can be built using the gradle-wrapper (on windows simply omit the prefix './'):
./gradlew war
Execute using gretty:
./gradlew appRun
Execute using jetty-runner (faster startup):
./gradlew startJettyRunner
Then access the example http://localhost:8080/zk-template-examples/locker/
Comments
| Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License. |