Greasemonkey: Добавить резервную копию / восстановить

Что ж, Firefox и его проблемы. Итак, я реализовал это (и, конечно же, функцию импорта). Я почти закончил с этим, но есть препятствие. Это работает только тогда, когда вы открываете browser toolbox и выбираете «не закрывать автоматически всплывающие окна». Импорт выполняется с помощью <input type="file"> (это единственный способ), однако при фокусе окна просмотра всплывающее окно обычно закрывается, поэтому окно уничтожается и никакие функции не выполняются. Соответствующие ошибки:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

Это так раздражает, когда приходится работать в неполноценной среде.

Также относится к № 2612. Которая может быть решена одновременно с этим вопросом.

@Sxderp Если закрытие всплывающего окна является проблемой, обычный способ решения /

Я могу сделать это. Это потребовало бы перемещения кучи кода. Я займусь этим как-нибудь в другой раз.

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

Я думаю, что в идеале пользователь мог бы заменить или объединить импорт. Стилус делает только слияние, что тоже плохой IME. Лучше всего кажется выбор пользователя со значениями по умолчанию, которые могут работать.

Конечно, но тогда мы сталкиваемся с множеством условных операторов. Я хотел бы увидеть какую-то блок-схему о _ точном_ характере слияния.

В основном в плане конфликтов. Перезаписывать контент, перезаписывать ключи / значения (да, они тоже экспортируются), запрашивать все (это похоже на плохой пользовательский интерфейс) и т. Д.?

Я имею в виду просто: импортируйте каждый сценарий в файл (и полностью перезаписывайте его до этого состояния), но не трогайте / не удаляйте сценарии, которых нет в файле.

Ой. Это намного проще. Да, звучит хорошо.

Итак, я реализовал три разных метода импорта.

1. Слияние. Не трогайте установленные скрипты. В базу данных будут добавлены только скрипты, которые в настоящее время не существуют [1].
2. Заменять. Удалите все текущие скрипты и замените их импортированными.
3. Перезаписать. Подобно слиянию, но если обнаружен конфликт [1], то импортируемые скрипты имеют приоритет.

Ожидание других PR перед отправкой.

[1] Я определяю уникальность по id скрипта.

Что насчет этого?

1. Обновлять. Импортируйте (перезаписывайте) только уже существующие скрипты.

Это дополнение к 1. Слияние

1. Перезаписать. Подобно слиянию, но если обнаружен конфликт [1], то импортируемые скрипты имеют приоритет.

@Sxderp Я полагаю, «Как слияние» не включает ограничение «Только скрипты, которые в настоящее время не существуют» ...
(это ограничение здесь не имеет смысла) Это означает, что Overwrite = Импортировать все скрипты, конфликтующие скрипты перезаписываются архивом ...

Какие из этих вариантов (обновление / слияние и т. Д.) Предлагает виртуальная машина, TM или другие варианты?

1. Обновлять. Импортируйте (перезаписывайте) только уже существующие скрипты.

Конечно, это возможно.

Это означает, что Overwrite = Импортировать все скрипты, конфликтующие скрипты перезаписываются архивом ...

Правильный.

Какие из этих вариантов (обновление / слияние и т. Д.) Предлагает виртуальная машина, TM или другие варианты?

На самом деле не уверен. Но это вызвало у меня другое беспокойство. Совместимость с архивами. Предполагая, что эти надстройки поддерживают полный экспорт базы данных (скрипты + данные), тогда в идеале импорт должен быть совместим друг с другом.

Обновлять. Импортируйте (перезаписывайте) только уже существующие скрипты.

Теперь, когда я думаю об этом (всего около 3 минут), у меня есть опасение. А как насчет связанных данных (get / setValue)? Следует ли сохранить данные, которые в настоящее время хранятся? Должны ли импортированные данные иметь приоритет? Какое-то слияние? А затем ясно представляя пользователю эту опцию / состояние. На самом деле это немного сложнее, чем на первый взгляд.

Сделал несколько быстрых проверок, это не на 100% тщательный, но дает общий обзор, а также то, что мне, вероятно, следует изменить в отношении моей реализации.

И виртуальная машина, и TM экспортируют в zip-файлы. Внутри zip-файлов вы можете найти файлы .user.js для каждого из ваших скриптов. Однако, что касается экспорта деталей, относящихся к хранилищу / реализации, они оба делают это немного по-разному. Виртуальная машина упаковывает конкретные детали реализации и данные сценария, которые выглядят как все сценарии, в один файл violentmonkey . TM делает это немного более разумно. Детали реализации для каждого сценария экспортируются в файлы .options.js , а данные сценария экспортируются в .storage.json .

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

Что касается «метода импорта» (описанного в моем сообщении выше):

TM предоставляет интерфейс «выбрать каждый сценарий». При импорте архива вы выбираете, хотите ли вы импортировать каждый конкретный сценарий. Если вы отметите его, он перезапишет все данные для этого скрипта.

Кажется, что виртуальная машина предлагает только то, что я описал выше как «перезапись». Однако есть возможность НЕ импортировать связанные данные сценария (глобальные для всех сценариев). С точки зрения пользовательского интерфейса, я думаю, что реализовать эту опцию в GM будет сложно. Однако, если мы воспользуемся подходом TM к экспорту / импорту базы данных, тогда пользователь может просто открыть архив и удалить файл .storage.json .

Если кто-то хочет протестировать, я обновил свою ветку sxderp:import-export-database-merge , добавив в нее описанную ранее функциональность .zip . Я не реализовал вариант update который предложил @Eselce, потому что я все еще не уверен в

@Sxderp Спасибо за разработку этой функции. Я собрал пакет и установил его в Firefox Developer Edition (чтобы разрешить установку неподписанных расширений). Я обновил существующий профиль этой версией браузера, перезаписал существующую установку GreaseMonkey и без проблем экспортировал свою базу данных.

Однако импорт в новый профиль Firefox с установленным GreaseMonkey вызвал проблему. Похоже, что один конкретный пользовательский скрипт, который довольно велик (и user.js, и gm_details.js имеют размер около 230 КБ, вызывает проблемы с импортом. После замены базы данных GM перестает работать. При нажатии на значок GM открывается пустой раскрывающийся список (около 10x10 квадратов).

Я бы предпочел не публиковать конкретный пользовательский скрипт публично. Используя этот трюк, я нашел ваш адрес электронной почты и отправлю вам сообщение.

Изменить: единственный способ заставить GM работать после того, как он сломается, - это удалить расширение, перезапустить Firefox и добавить его снова.

GMexport_20180 2 17_164139.zip ???

Импортировал целую кучу (частично) больших скриптов (> 20) из zip-файла размером 3,4 МБ без каких-либо жалоб. Но детального изучения нет ...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() начинается с 0 ... ; отсутствует ...

IIRC, getMonth () начинается с 0 ...; отсутствует...

РВАТЬ

Давно не работал над этой веткой. Я собираюсь взять сегодня, переустановить на master и сделать кучу очистки.

Я переустановил свою ветку на master и внес некоторые существенные изменения в макет, который, как мне кажется, обеспечивает лучшую читаемость.
@ArmEagle В моей обновленной ветке я смог импортировать отправленный вами файл. Если у вас все еще есть проблемы, дайте мне знать, и я займусь этим дальше.

Объединено с изменениями в 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09. Повторное открытие, чтобы отслеживать / обсуждать некоторые проблемы, которые я видел.

Повторное открытие, чтобы отслеживать / обсуждать некоторые проблемы, которые я видел.

Какие были проблемы?

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

Я наконец-то немного разобрался в этом.

Он поддерживает только .user.js и "детали". Что случайно включает требуемый контент, но пропускает ресурсы (JSON сериализует большой двоичный объект до {} ). AFAICT будет .setKnownResources() с пустыми / сломанными каплями и, следовательно, не сможет работать.

Было бы лучше, если бы у каждого сценария была своя собственная папка, эта папка содержала файл для основного .user.js , для каждого @require и @resource , а затем, возможно, оставшиеся проанализированные / пользовательские данные и сохраненные значения. Я думаю, что этого может быть даже лучше, чтобы я отказался от какой-либо кроссплатформенной совместимости.

Полностью согласен. Точно так же, как сохранение документа «как веб-страницу», при котором будет создан htm -документ плюс папка с таким же (базовым) именем с зависимостями ...

Что случайно включает требуемый контент ...

Не случайно. Включает его специально для любых локальных изменений, которые могли произойти. Я бы рассмотрел ресурсы / требования как «детали реализации» и, следовательно, экспортировал бы как «детали». ТМ даже не экспортирует ресурсы / требует.

но пропускает ресурсы (JSON сериализует большой двоичный объект до {}). AFAICT будет .setKnownResources () с пустыми / сломанными каплями и, следовательно, не работать.

Существует TODO, чтобы выяснить, хорошо ли структурированы капли. Эта функция была технически объединена до того, как я отправил ей PR.

На данный момент проблема с Blob будет решена с помощью # 2937.

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

Это «большая особенность» для 4.4, так что я очень надеюсь доработать / улучшить ее в ближайшее время.

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