Как сделать текст полная история в Django?

вам нужно ниже css

.custom-btns .btn-primary:not(:disabled):not(.disabled).active,
.custom-btns .btn-primary:not(:disabled):not(.disabled):active,.custom-btns .show>.btn-primary.dropdown-toggle {
    color: #000;
    background-color: yellow;
    border-color: yellow;
}
.custom-btns .btn-primary {
    color: #fff;
    background-color: #4CAF50;
    border-color: #4CAF50;
}
.custom-btns .btn-primary:hover {
    color: #fff;
    background-color: #3e9941;
    border-color: #3e9941;
}
.custom-btns .btn-primary.focus, .btn-primary:focus {
    box-shadow: 0 0 0 0.2rem #FFEB3B;
}

см. демо

9
задан 3 revs 23 May 2017 в 10:32
поделиться

5 ответов

Ваше автоматическое сохранение, я принимаю, сохраняет предварительную версию, прежде чем пользователь на самом деле нажмет кнопку сохранения, правильно?

Если так, Вы не должны сохранять проект, сохраняет, просто расположите их после того, как пользователь decideds, чтобы сохранить для реального, и только сохранить историю реального/явного сохраняет.

1
ответ дан 4 December 2019 в 22:30
поделиться

Для управления diffs Вы, вероятно, хотели бы исследовать difflib Python.

Относительно атомарности я, вероятно, обработал бы его то же как Wiki (Trac, и т.д.). Если содержание изменилось, так как пользователь в последний раз получил его, запросите, чтобы они переопределили с новой версией. При хранении текста и diffs в той же записи не должно быть трудно избежать условий состязания базы данных с помощью методов в ссылках, которые Вы отправили.

1
ответ дан 4 December 2019 в 22:30
поделиться

Проблема хранения: Я думаю, что необходимо только сохранить diffs двух последовательных действительных версий документа. Как Вы указываете, проблема становится получением действительной версии, когда параллельные редактирования происходят.

Проблема параллелизма:

  1. Вы могли избежать их всех вместе как Jeff, предлагает или путем блокировки документа?
  2. В противном случае я думаю, что Вы находитесь в конечном счете в парадигме совместных редакторов в реальном времени онлайн как Google Docs.

Для получения проиллюстрированного представления кучи проблем, Вы открываетесь, ловят этот технический разговор Google в 9m21 s (это о совместном редактировании Eclipse в реальном времени),

С другой стороны, существует несколько патентов, которые детализируют способы иметь дело с этими согласиями на статье Wikipedia о совместных редакторах в реальном времени.

2
ответ дан 4 December 2019 в 22:30
поделиться

Вот то, что я сделал для сохранения истории объекта:

Для приложения Django История:

история / __ init __. py:

"""
history/__init__.py
"""
from django.core import serializers
from django.utils import simplejson as json
from django.db.models.signals import pre_save, post_save

# from http://code.google.com/p/google-diff-match-patch/
from contrib.diff_match_patch import diff_match_patch

from history.models import History

def register_history(M):
  """
  Register Django model M for keeping its history

  e.g. register_history(Document) - every time Document is saved,
  its history (i.e. the differences) is saved.
  """
  pre_save.connect(_pre_handler, sender=M)
  post_save.connect(_post_handler, sender=M)

def _pre_handler(signal, sender, instance, **kwargs):
  """
  Save objects that have been changed.
  """
  if not instance.pk:
    return

  # there must be a before, if there's a pk, since
  # this is before the saving of this object.
  before = sender.objects.get(pk=instance.pk)

  _save_history(instance, _serialize(before).get('fields'))

def _post_handler(signal, sender, instance, created, **kwargs):
  """
  Save objects that are being created (otherwise we wouldn't have a pk!)
  """
  if not created:
     return

  _save_history(instance, {})

def _serialize(instance):
   """
   Given a Django model instance, return it as serialized data
   """
   return serializers.serialize("python", [instance])[0]

def _save_history(instance, before):
  """
  Save two serialized objects
  """
  after = _serialize(instance).get('fields',{})

  # All fields.
  fields = set.union(set(before.keys()),set(after.keys()))

  dmp = diff_match_patch()

  diff = {}

  for field in fields:
    field_before = before.get(field,False)
    field_after = after.get(field,False)

    if field_before != field_after:
      if isinstance(field_before, unicode) or isinstance(field_before, str):
      # a patch
        diff[field] = dmp.diff_main(field_before,field_after)
      else:
        diff[field] = field_before

  history = History(history_for=instance, diff=json.dumps(diff))
  history.save()

history/models.py

"""
history/models.py
"""

from django.db import models

from django.contrib.contenttypes.models import ContentType
from django.contrib.contenttypes import generic

from contrib import diff_match_patch as diff

class History(models.Model):
     """
     Retain the history of generic objects, e.g. documents, people, etc..
  """

  content_type = models.ForeignKey(ContentType, null=True)

  object_id = models.PositiveIntegerField(null=True)

  history_for = generic.GenericForeignKey('content_type', 'object_id')

  diff = models.TextField()

  def __unicode__(self):
       return "<History (%s:%d):%d>" % (self.content_type, self. object_id, self.pk)

Надежда, которая помогает кому-то и комментариям, ценилась бы.

Обратите внимание, что это не обращается к состоянию состязания моего самого большого беспокойства. Если, в _pre_handler "прежде = sender.objects.get (pk=instance.pk)" назван, прежде чем другой экземпляр сохраняет, но после, который другой экземпляр обновил историю, и существующий экземпляр сохраняет сначала, будет 'поврежденная история' (т.е. не в порядке). К счастью diff_match_patch пытается корректно обработать "нефатальные" повреждения, но нет никакой гарантии успеха.

Одним решением является атомарность. Я не уверен, как пойти о создании вышеупомянутого состояния состязания (т.е. _pre_handler) атомарная операция через все экземпляры Django, все же. Таблица HistoryLock или общий хеш в памяти (memcached?) был бы прекрасен - предложения?

Другим решением, как упомянуто, является алгоритм согласования. Однако параллельный сохраняет, может иметь "подлинные" конфликты и потребовать, чтобы вмешательство пользователя определило корректное согласование.

Очевидно, соединение истории назад не является частью вышеупомянутых отрывков.

3
ответ дан 4 December 2019 в 22:30
поделиться

Я с тех пор обнаружил django-возвращение, также, который, кажется, работает хорошо и активно сохраняется, хотя оно не делает разности для эффективного хранения маленького diffs к большим частям текста.

1
ответ дан 4 December 2019 в 22:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: