in reply to Re: Best way to handle locking of nodes being edited?
in thread Best way to handle locking of nodes being edited?

As a further clarification, I am still unconvinced that there is a problem with multiple editors editing at once. If a node requires editing, it is probably obvious what the edit is. Should 2 people race to do the same work, oh well.

At most have a message saying that "so and so started editing this time X ago" and let the editor decide whether they want to proceed.

  • Comment on Re (tilly) 2: Best way to handle locking of nodes being edited?

Replies are listed 'Best First'.
(tye)Re: Best way to handle locking of nodes being edited?
by tye (Sage) on Feb 23, 2001 at 00:53 UTC

    I agree. But since vroom asked, I assumed that he had a reason (such as wanting to implement automatic "undo").

    If you add to the above scheme a simple atomic test at final commit time to see whether the node has be changed since the editting began (as discussed already), then the editor can be warned that they are about to overwrite someone else's work. At that point, they can open another window and view the other work and decide whether to commit their own changes or not (or to merge some of the other editor's changes, etc.).

            - tye (but my friends call me "Tye")
Re: Re (tilly) 2: Best way to handle locking of nodes being edited?
by Adam (Vicar) on Feb 23, 2001 at 00:54 UTC
    Would that message clear when the "other" editor stubmit's the edit? Also, 'x' becomes a variable timeout, right?

      In an ideal world, the list of people editing a node (in the case of editors) or replying to a node (for everyone) would get cleared out after a pretty long time (like an hour), if the edit/reply is ever committed, or if the editor/replier hits "Cancel" (a new button whose sole purpose is to remove you from the list of editors/repliers for a node, just out of courtesy).

      But a first stab at this could skip the last item in the list to save development time.

              - tye (but my friends call me "Tye")
        replier? I thought we were only talking about editors here, not replies.

        As for the need for people to be able to "cancel", we would want that regardless of how we do the lock, right? I'm not sure I like the varaible timeout though. I kind of like the consistency enforced by the server doing a pessimistic lock.

        As a side note, I assume that editors will be able to preview the edit before it gets submitted, right?