ما الذي يمكنني فعله لمنع تعارضات الكتابة والكتابة على موقع ويب على طراز wiki؟

Question

على موقع ويب على طراز الويكي، ما الذي يمكنني فعله لمنعه أو تخفيفه صراعات الكتابة والكتابة مع السماح للموقع بالعمل بسرعة والحفاظ على سهولة استخدام الموقع؟

المشكلة التي أتوقعها هي:

1. يبدأ المستخدم "أ" في تحرير ملف
2. يبدأ المستخدم ب في تحرير الملف
3. ينتهي المستخدم "أ" من تحرير الملف
4. ينتهي المستخدم "ب" من تحرير الملف، ويستبدل بطريق الخطأ جميع تعديلات المستخدم "أ".

فيما يلي بعض الأساليب التي توصلت إليها:

• لديك نوع من نظام السحب / تسجيل الوصول / القفل (على الرغم من أنني لا أعرف كيفية منع الأشخاص من الاحتفاظ بملف مسحوب "لفترة طويلة جدًا"، ولا أريد أن يشعر المستخدمون بالإحباط بسبب عدم وجودهم مسموح لإجراء تعديل)
• لديك نوع من فرق نظام يُظهر تغييرات أخرى تم إجراؤها عندما يقوم المستخدم بإجراء تغييراته ويسمح بنوع من الدمج (لكنني أشعر بالقلق من صعوبة إنشاء هذا وسيجعل استخدام الموقع "صعبًا للغاية")
• إعلام المستخدمين بالتعديلات المتزامنة بينما إنهم يقومون بإجراء تغييراتهم (نوع من AJAX؟)

هل هناك طرق أخرى للذهاب في هذا؟هل هناك أي أمثلة على المواقع التي تنفذ هذا بشكل جيد؟

Answer 1

تذكر رقم الإصدار (أو المعرف) للتغيير الأخير.ثم اقرأ الإدخال قبل كتابته وقارن ما إذا كان هذا الإصدار لا يزال كما هو.

في حالة وجود تعارض، قم بإبلاغ المستخدم الذي كان يحاول كتابة الإدخال الذي تم تغييره في هذه الأثناء.ادعموه بالفرق.

معظم مواقع الويكي تفعل ذلك بهذه الطريقة. ميدياويكي, Usemod, إلخ.

Answer 2

الدمج الثلاثي: أول شيء يجب الإشارة إليه هو أن معظم التعديلات المتزامنة، خاصة على المستندات الأطول، تكون على أقسام مختلفة من النص.ونتيجة لذلك، من خلال ملاحظة المراجعة التي حصل عليها المستخدمان A وB، يمكننا إجراء دمج ثلاثي، كما هو مفصل بواسطة بيل ريتشر من Guiffy Software.يمكن للدمج الثلاثي أن يحدد مكان إجراء التعديلات من النص الأصلي، وما لم يتعارضا، فيمكن دمج كلا التعديلين بصمت في مقالة جديدة.من الناحية المثالية، في هذه المرحلة، قم بتنفيذ الدمج وأظهر للمستخدم "ب" المستند الجديد حتى يتمكن من اختيار مراجعته بشكل أكبر.

حل التصادم:يتركك هذا مع السيناريو الذي يقوم فيه كلا المحررين بتحرير نفس القسم.في هذه الحالة، قم بدمج كل شيء آخر وتقديم نص الإصدارات الثلاثة إلى المستخدم "ب" - أي تضمين النسخة الأصلية - مع إصدار المستخدم "أ" في مربع النص أو إصدار المستخدم "ب".يعتمد هذا الاختيار على ما إذا كنت تعتقد أن الإعداد الافتراضي يجب أن يكون قبول الأحدث (ينقر المستخدم فقط على "حفظ" للاحتفاظ بإصداره) أو إجبار المحرر على التعديل مرتين للحصول على تغييراته (يجب عليه إعادة تطبيق تغييراته على المحرر "أ"). نسخة القسم).

يؤدي استخدام الدمج الثلاثي بهذه الطريقة إلى تجنب عمليات القفل، التي يصعب جدًا التعامل معها بشكل جيد على الويب (إلى متى تسمح لهم بالحصول على القفل؟)، والسيناريو المتفاقم "قد ترغب في البحث مرة أخرى"، والذي لا يؤدي إلا إلى يعمل بشكل جيد للاستجابات على غرار المنتدى.كما أنه يحتفظ بأسلوب ما بعد الاستجابة للويب.

إذا كنت تريد إجراء عملية Ajax قليلاً، فقم بدمج إصدار المستخدم "أ" ديناميكيًا بثلاثة اتجاهات في إصدار المستخدم "ب" أثناء قيامهم بتحريره, ، وأبلغهم.الآن هذا سيكون مثير للإعجاب.

Answer 3

في Mediawiki، يقبل الخادم التغيير الأول، ثم عندما يتم حفظ التعديل الثاني، تظهر صفحة تعارضات، ثم يقوم الشخص الثاني بدمج التغييرين معًا.يرى ويكيبيديا:مساعدة:تحرير التعارضات

Answer 4

من المحتمل أن يكون استخدام آلية القفل هو الأسهل في التنفيذ.يمكن أن يكون لكل مقالة حقل قفل مرتبط بها ووقت قفل.إذا تجاوز وقت القفل بعض القيمة المحددة، فستعتبر القفل غير صالح وتقوم بإزالته عند مراجعة المقالة للتعديل.يمكنك أيضًا تتبع الأقفال المفتوحة وإزالتها عند إغلاق الجلسة.ستحتاج أيضًا إلى تنفيذ بعض التحكم في التزامن في قاعدة البيانات (ربما الطوابع الزمنية التي يتم إنشاؤها تلقائيًا) حتى تتمكن من التأكد من أنك تتحقق من تحديث للإصدار الذي قمت بسحبه، فقط في حالة تمكن شخصين من تحرير المادة في نفس الوقت.لن يتمكن سوى الشخص الذي لديه الإصدار الصحيح من التحقق من التعديل بنجاح.

قد تتمكن أيضًا من العثور على محرك اختلافات يمكنك استخدامه لإنشاء الاختلافات، على الرغم من أن عرضها في محرر wiki قد يكون مشكلة - في الواقع قد يكون عرض الاختلافات أصعب من إنشاء الاختلافات.ستعتمد على نظام الإصدار لاكتشاف الوقت الذي تحتاج فيه إلى رفض التعديل وإجراء اختلاف.

Answer 5

في Gmail، إذا كنا نكتب ردًا على بريد وأرسل شخص آخر ردًا بينما لا نزال نكتبه، فستظهر نافذة منبثقة تشير إلى وجود تحديث جديد ويظهر التحديث نفسه كمنشور آخر دون إعادة تحميل الصفحة.يناسب هذا الأسلوب احتياجاتك، وإذا كان بإمكانك استخدام Ajax لإظهار المنشور الدقيق مع رابط لاختلاف ما تم تحديثه للتو بينما لا يزال المستخدم "ب" مشغولاً بكتابة إدخاله، فسيكون ذلك رائعًا.

Answer 6

كما قال رافي (وآخرون)، يمكنك استخدام أسلوب AJAX وإبلاغ المستخدم عند حدوث تغيير آخر.عند إرسال تعديل، ما عليك سوى الإشارة إلى الاختلافات النصية والسماح للمستخدم الثاني بمعرفة كيفية دمج النسختين.

ومع ذلك، أود أن أضيف شيئًا جديدًا يمكنك تجربته بالإضافة إلى ذلك:افتح مربع حوار الدردشة بين المحررين أثناء إجراء تعديلاتهم.يمكنك استخدام شيء مثل Embedded ثرثرة لذلك، على سبيل المثال.
 
 
أقول إن أفضل حل للصراع هو الحوار المباشر.

Answer 7

تم حل مشكلتك (التحديث المفقود) بشكل أفضل باستخدام التحكم المتفائل في التزامن.

أحد التطبيقات هو إضافة ملف إصدار عمود في كل كيان قابل للتحرير في النظام.عند تحرير المستخدم، تقوم بتحميل الصف وعرض نموذج html على المستخدم.دعنا نقول أن الحقل المخفي يعطي الإصدار 3.يجب أن يبدو استعلام التحديث كما يلي:

update articles set ..., version=4 where id=14 and version=3;

إذا كانت الصفوف التي تم إرجاعها هي 0، فهذا يعني أن شخصًا ما قد قام بالفعل بتحديث المادة 14.كل ما عليك فعله بعد ذلك هو كيفية التعامل مع الموقف.بعض الحلول الشائعة:

1. الالتزام الأخير يفوز
2. الالتزام الأول يفوز
3. دمج التحديثات المتعارضة
4. دع المستخدم يقرر

بدلا من تزايد إصدار int/long يمكنك استخدام a الطابع الزمني ولكن لم يتم اقتراحه للأسباب التالية:

استرجاع الوقت الحالي من JVM ليس بالضرورة آمنًا في بيئة مجمعة، حيث قد لا تكون العقد متزامنة مع الوقت.

(اقتباس من استمرار جافا مع السبات)

بعض مزيد من المعلومات في وثائق السبات.

Answer 8

في مكتبي، لدينا سياسة مفادها أن جميع جداول البيانات تحتوي على 4 حقول:

• انشأ من قبل
• تاريخ الإنشاء
• التحديث الأخير بواسطة
• اخر تاريخ تحديث

وبهذه الطريقة يكون هناك مسار تدقيق جيد حول من فعل ماذا بالسجلات، على الأقل في الآونة الأخيرة.

ولكن الأهم من ذلك، أنه يصبح من السهل بما فيه الكفاية مقارنة LastUpdateDate للسجل الحالي أو المحرر على الشاشة (يتطلب منك تخزينه على الصفحة، في ملف تعريف الارتباط، أيًا كان، مع القيمة الموجودة في قاعدة البيانات.إذا كانت القيم غير متطابقة، فيمكنك أن تقرر ما يجب فعله من هناك.