You are here: Foswiki>Tasks Web>Item10788 (10 Jan 2012, MichaelDaum)Edit Attach

Item10788: Reduce edit collisions with EditChapterPlugin

pencil
Priority: Urgent
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: EditChapterPlugin
Branches:
Reported By: AndreLichtsteiner
Waiting For:
Last Change By: MichaelDaum
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 (REFACTOR 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 smile
      • 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 smile

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
 
Topic revision: r11 - 10 Jan 2012, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy