Last edit 2007-03-16 21:23:49 by JørnWildt [ Removing Franky's rant ]

Additions
4. User B saves his work and thereby overwrites user A's work without even knowing it. .

Deletions

4. User B saves his work and thereby overwrites user A's work.
Usually everything is fine, because in this example, A is a woman and B is a man. But sometimes we have to take care about what they say (there is a 50% chance that they are right).

_EDITED 2007-03-07 18:00:56 by Landseer [ ]

Additions
Usually everything is fine, because in this example, A is a woman and B is a man. But sometimes we have to take care about what they say (there is a 50% chance that they are right).

Deletions
Usually everything is fine, because in this example, A is a woman and B is man. But sometimes we have to take care about what they say (there is a 50% chance that they are right).

Oldest known version of this page was edited on 2007-03-07 17:01:34 by Landseer [ minor change :-D ]

Single user page access using PageLock module


The core PageLock module can be used to restrict access to a certain page in such a way that only one user at a time has access to it. This can be used to avoid a classic concurrency problem:
1. User A starts editing an article.
2. User B edits the same article.
3. User A saves her work.
4. User B saves his work and thereby overwrites user A's work.

Usually everything is fine, because in this example, A is a woman and B is man. But sometimes we have to take care about what they say (there is a 50% chance that they are right).

If we add a page locking feature to the editing page then this would happen instead:
1. User A starts editing an article.
2. User B edits the same article. But the page is overlaid with a dark transparent skin that blocks the interface. In the middle there's a message "This page is locked by another user" plus some more detailed information about the lock.
3. User B waits until A is finished editing.
4. After some time user A commits her work and user B's window automatically reloads with the new data ready to edit.

This is what the PageLock module will do for you. When user A opens her window it will register it and start pinging the server (using AJAX) every X sec. to ensure the lock is kept. When user B opens his window then it is blocked, but keep pinging the server (also using AJAX) until user A releases the lock.

All you need to do is to call two API functions and pass in two variables:
1. A lock name.
2. A return URL for returning from a blocked window (when user B gives up and presses "cancel").

To require a lock you add the code below right before your function finishes (typically right before or after fecthing HTML from the render object):

    $returnUrl = pnModUrl('howtopnforms', 'recipe', 'view',
                          array('rid' => $this->recipeId));

    pnModAPIFunc('PageLock', 'user', 'pageLock',
                 array('lockName' => "HowtoPnFormsRecipe{$this->recipeId}",
                       'returnUrl' => $returnUrl));


This will add some JavaScript? in the page header that will take care of the rest.

To release a lock you add this code right after handling user buttons (cancel or submit):

      pnModAPIFunc('PageLock', 'user', 'releaseLock',
                   array('lockName' => "HowtoPnFormsRecipe{$this->recipeId}"));


You can find the complete example in the HowToPnForms∞ module (pnrecipe.php).

Lock name scheme


If all of this is to work then we must use a consistent lock name scheme. I suggest to concatenate module name, table name, and edited item ID: "<Module><Table><ID>" - like for instance "HowtoPnFormsRecipe42?".

Zikula .8 implementation


The PageLock module was added too late to make it in the .8 version, so you can only find examples in the HowToPnForms? module.
Last edit: 2007-03-16 21:23:49
Latest author: JørnWildt
Owner: JørnWildt