Item10788: Reduce edit collisions with EditChapterPlugin
Priority: Urgent
Current State: Closed
Released In: n/a
Target Release: n/a
We use Foswiki for a whole lot of different tasks, among is meeting minutes taking, where all participants provide there known contributions before the meeting starts in a shared wiki topic. As closer the meeting gets, the higher the activities on the topic become. Often several user add there contribution concurrent, encouraged by Foswikis alleged capability to merge all those contributions. But, unfortunately, Foswiki creates to often ugly collision topics, even if author where clearly working in different sections.
Users are specially disappointed, because the topics are well prepared with all the necessary headers and all contributor agreed on only edit there respective sections by editing with chapter edit (
Icon next to the headers).
We now added the following functionality to
EditChapterPlugin:
- If editing a topic was invoked by chapter edit, save tests, whether the topic has changed in the meantime:
- If the topic has not changed: proceed without addition action
- If the topic has changed: check, whether the chapter, the author is currently editing has changed
- If the chapter has changed: proceed without addition action. Lets Foswikis collision resolving try its best
- If the chapter has not changed: Update in the current editing page the areas before and after the edited chapter and update the original revision info. Foswiki will save the topic, as if the edit sessions where sequential and not parallel
The following code was created:
Wenn mehrere User gleichzeitig an einem Wiki Topic arbeiten kommt es beim speichern zwangsläufig zu einem Konflikt. Foswiki versucht die parallel gemachten Änderungen einvernehmlich zusammenzuführen, doch mit sehr unterschiedlich Resultaten. Häufiger als eigentlich nötig, wird bei Konflikten das Topic mit zahlreichen
ins
und
del
Tags durchsetzt. Dies leider oft auch unnötig, wenn die User nämlich EditChapterPlugin einsetzten und nur in einem getrennten Bereich gearbeitet haben.
Dieses Modifikation soll die Zahl der erfolglosen Merger im Einsatz mit EditChapterPlugin stark reduzieren.
Die Verbesserung scheitert:
- Zwei Nutzer ändern gleichzeitig das selbe Kapitel
- Die Überschriften Struktur ändert sich, so dass ein soeben verändertes Kapitel zum Zeitpunkt der Speicherung nicht mehr an der selben Stelle zu stehen kommt wie zuvor
Sollte die Verbesserung scheitern, kommt weiterhin Foswikis Merge Funktion zu Zug.
edited File
-
templates/edit.chapter.tmpl
-
*** 2,4 ****
%TMPL:INCLUDE{"editjavascript"}%<!-- editjavascript// -->
- %TMPL:DEF{"textarea"}%<!-- textarea -->
+ %TMPL:DEF{"textarea"}%<!-- textarea -->%TMPL:P{"neweditchapter"}%
%TMPL:DEF{"neweditchapter"}%
<textarea id="topic_0" name="paragraph_0" style="display:none">%EXTRACTCHAPTER{from="%URLPARAM{"from" default="0"}%" to="%URLPARAM{"to"}%" encode="on" id="1"}%</textarea>
<literal>
<script >
var oldbeforeSubmitHandler = beforeSubmitHandler;
beforeSubmitHandler = function(script, action) {
// Only in case of an action 'save'
if (action == 'save') {
// get current topic version from server (synchronous)
$.ajax({
url: '%TOPICURL%?cover=chapterrevision',
async: false,
success: function(data) {
version_disk = data;
}
});
// has the version on the server in the meantime (while I was writing)
if (jQuery('[name=originalrev]').val() != version_disk) {
// get the synchronous content from the server, again split into chapter (synchronous)
$.ajax({
url: '%TOPICURL%?cover=chapteredit&from=%URLPARAM{"from" default="0"}%&to=%URLPARAM{"to" default="0"}%',
async: false,
dataType: 'html',
success: function(data) {
// currently edited chapter
version_disk_chapter = $(data).filter('#paragraph').val();
// section before and after the edited chapter
version_disk_beforetext = $(data).filter('#beforetext').val();
version_disk_aftertext = $(data).filter('#aftertext').val();
},
error: function() { alert("error"); }
});
// is the edited chapter in the current version unchanged, since I started editing
if (version_disk_chapter == jQuery('#topic_0').val()) {
// replace the section before and after my chapter with the current version from the server
jQuery('#beforetext').val(version_disk_beforetext);
jQuery('#aftertext').val(version_disk_aftertext);
// update the form filed 'originalrev' to pretend, we started our edit session based on the current version
jQuery('[name=originalrev]').val(version_disk);
}
}
}
// start the original EditChapterPlugin beforeSubmitHandler
if (oldbeforeSubmitHandler != null) {
oldbeforeSubmitHandler();
}
}
</script>
</literal>%TMPL:END%
new Files
-
templates/view.chapterrevision.tmpl
(new) - To get the current topic revision information
%REVINFO{"$rev_$epoch"}%
-
templates/view.chapteredit.tmpl
(new) - To get the topics content split in beforetext, paragraph (selected chapter) and aftertext.
<noautolink>
<textarea id="beforetext">%EXTRACTCHAPTER{before="%URLPARAM{"from" default="0"}%" encode="on" id="2"}%</textarea>
<textarea id="paragraph">%EXTRACTCHAPTER{from="%URLPARAM{"from" default="0"}%" to="%URLPARAM{"to"}%" encode="on" id="1"}%</textarea>
<textarea id="aftertext">%EXTRACTCHAPTER{after="%URLPARAM{"to"}%" encode="on" id="3"}%</textarea>
</noautolink>
We would like to see this improvement in
EditChapterPlugin.
To the author of the Plugin - dear
MichaelDaum - feel free to take the code and add what ever fits best.
--
AndreLichtsteiner - 25 May 2011
I see what you mean. Alas, the patch seems to lower the burden to hell even more. As far as I see you are trying to merge chapters on the client side to prevent the sub-optimal standard merge on the server side to create lots of ins and dels. Not sure if I get the patch right.
--
MichaelDaum - 25 Aug 2011
As I understood, EditChapterPlugin merges the parts
beforetext
,
text
and
aftertext
together on the client side.
This patch just updates
beforetext
and
aftertext
, in case:
- the topic has changed while an author is writing
- but the edited chapter remained unchanged
--
AndreLichtsteiner - 25 Aug 2011
I see. This might very well be a good idea to do. Or maybe this approach is flawed by design because - as you already said yourself - the chapter structure might be changed by an edit of
beforetext
. So
fetching an up-to-date version before combining all three comes out strange. I can see this kind of chapter-based "merge" might be better than the bloody ins & dels.
Maybe a chapter-based merge (done on the server-side) is preferable even for the standard behavior: flag larger chunks of being in conflict rather than trying to merge prose per character.
What are your real-world experiences with it?
Still, this points out that there's a warning message missing like in normal edit where the user is informed about somebody else already editing the topic. This is the reason a merge as part of an edit-chapter is happening more often than during a normal edit.
--
MichaelDaum - 26 Aug 2011
We experience, that the users are happier the lesser they see the conflict warning message
But, you are right, having this chapter merge as a general feature would be nice. And an optional dialogue, informing about a successful merger would not hurt.
--
AndreLichtsteiner - 29 Aug 2011
For now I've added rest calls to properly lock/unlock in 4.10. Please have a check.
--
MichaelDaum - 29 Aug 2011
Having Chapter Edit in a modal dialogue looks nice. But it looks like that the modal dialogue with a NatEdit on top of Pattern Skin is not able to open another dialogue: link, image etc. We consider this a bug.
--
AndreLichtsteiner - 06 Sep 2011
All modal dialogs will be reworked to use jquery-ui.dialog instead of jquery.simplemodal. And these will be able to stack properly.
The initial bug report has been fixed. So I am closing this one.
--
MichaelDaum - 10 Jan 2012