Comments 12
А почему не рассматривается вариант trans-user redo? То есть у вас же очередь изменений на сервере линейная, почему не разрешить пользователю А отменять изменения пользователя Б? Желательно, конечно при этом показывать, что произойдет и, если изменения не пересекаются, дать пользователю возможность отменять только те изменения, которые он сам внёс.
0
С точки зрения документа предложенный вами вариант (trans-user undo/redo) единственно правильный. Но с точки зрения пользователя так делать нельзя, потому что пока первый пользователь набирает что-то, второй захочет сделать Undo, но будет делаться Undo не тем действиям, каким он планировал, а тем, которые сейчас делает первый пользователь.Делать Undo только для непересекающихся действий тоже сомнительный вариант, потому что сделали мы три действия, например, а откатить можем только первое и третье. Это будет странно выглядеть для пользователя, что два раза Undo сработало, а один раз — нет.
0
Я себе представляю это так: Алиса редактирует абзац 1, Боб «одновременно» редактирует абзац 2. Алиса хочет сделать redo — поскольку у она не вносила изменения, которые пересекаются с Бобом — просто предлагаем Алисе откатить изменения в абзаце 1. Далее Алиса переносит предложение из абзаца 1 в абзац 2 и они с Бобом продолжают работать, внося еще изменения — Алиса в абзац 1, Боб — 2. Далее Боб решает откатить изменения и сначала система отменяет изменения которые он внёс в абзац 2, затем, когда черёд доходит до переноса предложения из абзаца 1 в абзац 2, Боб получает уведомление, что вот, мол, дальше откатить необходимо чужое изменение, при этом Бобу показывают, что случится, он соглашается, Алиса тоже получает апдейт.
0
Так можно сделать, но тогда быстрое совместное редактирование превратится в пошаговое, потому что чтобы Бобу добраться до изменения, которое он хочет откатить, нужно чтобы никто в этот момент больше в документе ничего не правил. Такое редактирование «быстрым» уже будет сложно назвать.
0
не в документе в целом, но в той его части, над которой работает Боб — да. Ну и блокировка не нужна, просто undo становится не совсем undo, а скорее "-do". В этом смысле лучше даже не как undo это представлять, а как историю изменений, в которой в любой момент можно отменить любое из них. То есть существует как бы две истории:
1. История версий документа, которая линейная и в которой понятия «undo» может и не быть, с точки зрения истории документа undo — это лишь противоположные действия добавленные в соотв. порядке, назовём их antidiff. В многопользовательской среде при этом могут параллельно добавляться другие изменения и вклиниваться между «undo».
2. С точки зрения пользователя существует история его действий (diff) «смешанная» с действиями других пользователей, если они вносили изменения в те блоки, где работал пользователь. Пользователь мог бы иметь возможность откатывать эти действия, при этом в истории версий документа действия только лишь добавляются. Во множестве случаев результат такого «undo» будет аналогичен Ворду.
Блокировка требуется только в том случае, если кто-то решить откатится на старую версию в дереве номер 1. Такую возможно тоже можно добавить, мне кажется. При этом, конечно, желательно отменённые изменения из дерева 1 сохранять как рид-онли ветки.
1. История версий документа, которая линейная и в которой понятия «undo» может и не быть, с точки зрения истории документа undo — это лишь противоположные действия добавленные в соотв. порядке, назовём их antidiff. В многопользовательской среде при этом могут параллельно добавляться другие изменения и вклиниваться между «undo».
2. С точки зрения пользователя существует история его действий (diff) «смешанная» с действиями других пользователей, если они вносили изменения в те блоки, где работал пользователь. Пользователь мог бы иметь возможность откатывать эти действия, при этом в истории версий документа действия только лишь добавляются. Во множестве случаев результат такого «undo» будет аналогичен Ворду.
Блокировка требуется только в том случае, если кто-то решить откатится на старую версию в дереве номер 1. Такую возможно тоже можно добавить, мне кажется. При этом, конечно, желательно отменённые изменения из дерева 1 сохранять как рид-онли ветки.
0
Статье не хватает технических подробностей, без них она выглядит как промо-материал «какие мы молодцы, что сделали то, что хотели наши клиенты».
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
Например, какая у вас статистика запросов; сколько у вас серверов, чтобы выдерживать обновления каждые 1/25 сек.; какой стек технологий используется для реализации; etc…
+3
OpenSource версии редакторов уже поддерживают этот функционал? Можно обновляться?
0
меню «Файл» — вкладка «Дополнительные параметры» — «Co-editing mode».
Либо все английским, либо всё по-русски.
0
Sign up to leave a comment.
Что ж, этот день настал: быстрое совместное редактирование в редакторах ONLYOFFICE