Изменения редакции - визуально показывающие изменения - PullRequest
1 голос
/ 24 февраля 2010

откат статьи


Я удалил большую часть этого вопроса, потому что понял, что должен перефразировать его. Вот это перефразировка:

Как я могу реализовать что-то со сквозными ударами? Сравнение одного ревизионного обновления с предыдущим. Я не хочу ревизии или контроля версий как таковых, потому что я могу просто обработать это в моей базе данных mySQL, но я хочу иметь возможность визуально идентифицировать изменения с зеленым и красным штрихом через обновления почти в журнале изменений нравится страница (если пользователь желает ее увидеть).

Я видел что-то похожее в изменениях ревизий на SO, и хотел бы иметь что-то подобное?

Мне кажется, мой вопрос сейчас принципиально отличается от оригинала, извините

Но здесь: https://stackoverflow.com/posts/2326658/revisions

Ответы [ 6 ]

3 голосов
/ 10 марта 2010

Часть-1: структура данных (из исходного вопроса) :

  1. Одна строка для версии -VS- все версии в одной строке:
    Сохраняйте одну ревизию на строку, не упаковывайте все ревизии в одну строку в виде XML или любых других многозначных типов поддержки. Первоначально статья может быть отредактирована несколько раз, и авторы будут запрашивать ее ревизию, но позже ваша заявка будет запрашивать только самую последнюю версию. В этом случае нет смысла загружать всю историю изменений.

  2. Одна таблица -VS- две таблицы:
    Third_normal_form предлагает использовать 2 таблицы:
    - Article[ActicleID(int,PK), AuthorID(int,FK), ...]
    - ArticleRevisions[ArticleID(int,UK), RevisionID(int,UK), Content, RevisionComment, RevisionTimeStamp, ...]
    В любом случае храните полные статьи и не играйте с реализацией типа delta - ваш вариант использования требует не сложности, а простоты. Также вы можете избыточно сохранить LatestRevisionID в таблице Article для более удобного поиска последней версии.
    Вы можете выбрать решение с одной таблицей. Для примера посмотрите на строку 76 (Table('wiki'...) в схеме базы данных Trac . Также вы можете посмотреть, как Trac делает это для своих простых вики, посмотрев пример их истории ревизий и revision diff , которые очень похожи на те на StackOverflow.

Часть-2: обнаружение и представление различий между двумя ревизиями :
Прежде всего, никто не визуально идентифицирует изменения, а скорее программно . Что вам нужно, это библиотека, в которой два файла (строки / списки строк) предоставят вам результаты сравнения. Во многих случаях выбирается построчное сравнение, так как сделал stackoverflow ). Затем вам нужно представить эти результаты для использования (с зелеными, красными, зачеркнутыми и т. Д.).

Хотя у меня мало знаний о PHP и его библиотеках, вам следует начать со следующих ссылок:

2 голосов
/ 24 февраля 2010

Ваше предложение звучит для меня совершенно разумно: одна таблица со строкой для каждой ревизии и одна таблица со строкой для "отображаемой статьи", которая эффективно ссылается на текущую ревизию в таблице ревизий. Что в этом подробного?

Вы можете подделать его с каким-то "текущим" столбцом в одной таблице, но тогда вам нужно будет убедиться, что для какой-то конкретной статьи актуальна только одна ревизия, что звучит довольно неприятно для меня.

1 голос
/ 09 марта 2010

Попробуйте сохранить его как XML

Насколько я могу понять проблему. Это может быть решено, если мы будем хранить каждую строку как строку. Но это будет плохо, потому что количество строк значительно увеличивается.

Сохраняйте данные подряд как

<row num=1>How would you structure something like this. I want to allow my authors to create articles. However, </row>
<row num=2>should they choose, I would like to be able to allow each save to be a new revision and then allow each </row>
............

Все в одной строке, но в формате xml. Когда вы получите его, вы можете сравнить строки, используя атрибут num.

0 голосов
/ 10 марта 2010

Я не могу сказать, имеете ли вы дело с кодами различий или более общими документами. Несколько лет назад я реализовал реализацию, которая отображала различия версий вики-документов, причем две версии располагались рядом, удаления отмечены красным цветом в старой версии, дополнения зеленым цветом в новой версии. Все это было сделано в javascript, сначала извлекая только текстовые части HTML, разбирая их (используя diff_match_patch.js ), а затем используя результаты diff, чтобы определить, что выделить (используя стили для изменения цветов фона). ). Это было довольно сложно, не идеально (но достаточно близко) и включало довольно много манипуляций с DOM. Так что выполнимо, но не просто.

0 голосов
/ 09 марта 2010

Если я правильно понимаю ваши теги, вы ищете реализацию diff в PHP. Правильный? То, как вы храните его в своей базе данных, зависит от факторов, которые мы не можем увидеть прямо сейчас - мы не знаем, что вы планируете делать с несколькими языками и тому подобное. В любом случае, останется только то, что каждая ревизия будет каким-то образом записана как поле mysql text в записи. Затем вы бы сравнили две из этих ревизий, используя diff.

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

В зависимости от конфигурации вашего сервера, вы также можете использовать командную строку Linux diff, например.

0 голосов
/ 24 февраля 2010

Ваш вопрос можно резюмировать как "как реализован контроль версий?" Обычно каждая ревизия хранится в виде различий из старой версии вместо всего текста снова (хотя есть много вариантов). Большинство систем могут / будут хранить все версии, завершенные для нетекстовых форматов, которые они не могут изолировать изменения в «строки».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...