Как сохранить настройки для приложения? - PullRequest
1 голос
/ 22 марта 2011

Я новичок в Ruby, пришедший из веб-разработки, в основном с PHP / SQL. Я думал о том, как сохранить настройки в своем приложении. Например, если я хочу сохранить путь как default_path и установить его также при перезапуске приложения пользователем.

В мире Интернета, вероятно, можно хранить это в базе данных или XML. База данных кажется излишней для отдельного приложения. Но я не уверен, что XML / YAML / Other-Write-Format - это то, что нужно. И если да, то где мне хранить эти настройки? Должны ли они быть, например, на Mac, в ~ / Library / MyAppName?

Ответы [ 3 ]

2 голосов
/ 22 марта 2011

Мне нравится использовать YAML, потому что он очень легко читается / пишется многими языками, позволяя нескольким приложениям совместно использовать одну и ту же информацию о конфигурации. Это хорошо документированный стандарт, поэтому вероятность того, что данные попадут в дыру, очень мала.

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

Небольшая креативная кодировка с вашей стороны, которая периодически проверяет время последнего изменения файла YAML, может сделать его таким, чтобы ваше приложение могло изменять его поведение на лету, так как файл prefs настроен. У меня было большое приложение, которое я не хотел закрывать на изменения и настраивать это поведение. Он работал три недели подряд, и я настроил его рабочие параметры через его конфигурационный файл. Он будет читать файл каждую минуту и ​​наследовать любые изменения его параметров на лету.

Базы данных - хороший способ хранения параметров / предпочтений, если это централизованный сервер или веб-приложение. Для чего-то распределенного, работающего на отдельных машинах, это не имеет смысла.

1 голос
/ 22 марта 2011

Ruby предоставляет вам другой метод хранения данных, который называется Marshaling . Это позволит вам сохранить класс / объект в файле и восстановить его позже. Если все ваши пользовательские настройки хранятся в одном объекте (или вы можете создать объект, который может содержать все необходимые вам данные), может быть проще упорядочить данные, чем записывать процедуры импорта / экспорта в текстовые основанный формат или попытка получить дополнительную библиотеку или гем.

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

Обновление: Простейший пример маршалинга, вероятно, будет следующим: скажем, у вас есть класс с именем UserPrefs, который вы используете для хранения всех ваших пользовательских настроек. Вы можете использовать следующий код для сохранения данных настроек в файл:

my_prefs = UserPrefs.new
# ... Fill in the 'my_prefs' object with the user's preferences, etc ...

# Store the object into a file
File.open("user_prefs.data", "wb") do |file|
   Marshal.dump(my_prefs, file)
end

При следующей загрузке приложения вы можете восстановить эти настройки, используя следующую команду:

# Load prefs from file
my_prefs = nil
File.open("user_prefs.data", "rb") {|f| my_prefs = Marshal.load(f)}

На этом этапе объект my_prefs должен быть точно таким же, каким он был при первоначальном запуске кода маршалинга. По сути, это позволяет вам делать «снимок» объекта в определенный момент времени (скажем, когда ваша программа завершает работу) и восстанавливать его позже (например, когда ваша программа загружается). Внутри все данные в структуре закодированы в одну строку, и эта строка хранится на диске; модуль Marshal просто заботится о кодировании и декодировании для вас.

Здесь - еще один пример использования маршалинга для хранения и извлечения данных.

Процедуры кодирования / декодирования по умолчанию, встроенные в модуль Marshal, обычно достаточны для большинства классов хранения данных. Особенно сложные классы могут иметь проблемы, и если это так, то вы можете определить свои собственные методы кодирования и декодирования ( первая ссылка включает пример определения пользовательских методов).

Однако некоторые типы данных нельзя маршалировать (например, дескрипторы для открытия файлов, Proc объекты и т. Д.), Поскольку они обычно не сохраняются в сеансах Ruby. Если вам нужно маршалировать класс, который включает в себя такие элементы, которые не нравятся Marshal, вы можете использовать пользовательские функции кодирования / декодирования, чтобы маршалировать остальную часть класса и опускать проблемные элементы.

0 голосов
/ 22 марта 2011

Я видел некоторые приложения, использующие ruby ​​gconf2

...