2014-10-13 2 views
0

Я хочу сохранить настройки для моих пользователей и некоторые из них были бы один из предопределенного списка! Использование https://github.com/ledermann/rails-settings Банкомат.Лучшие практики в отношении каждого пользователя настройки и предопределения параметры

Установка для f.e. weight_unit будет отсутствовать [: kg,: lb].

Я действительно не хочу жестко кодировать этот материал в контроллер или код просмотра.

Это своего рода общей функциональности, поэтому мне было интересно: Кто-нибудь придумать каким-то способом абстрагирования, что бизнес в класса константа или в базы данных в СУХОЙ моде?

ответ

1

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

В вашем случае вы можете создать новый столбец в своей таблице пользователей (например, назовите его «настройки»).

После этого добавить к пользовательской модели

serialize :settings, Hash 

с этого момента вы можете положить все, что вы хотите в настройках, например

user.settings = {:weight_unit => :kg, :other_setting1 => 'foo', :other_setting2 => 'bar'} 

и сохранение с user.save вы получите в столбец настроек, сериализованные данные.

Rails также де-сериализует его, поэтому после извлечения пользовательской записи, вызывая user.settings, вы получите все сохраненные настройки для пользователя.

Чтобы получить более подробную информацию о сериализации(), обратитесь к документации: http://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/Serialization/ClassMethods.html#method-i-serialize

Update1 Чтобы убедиться, что настройки в предопределенном списке вы можете использовать валидации на модели пользователя.

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

ALLOWED_SETTINGS = {:weight_unit => [:kg, :lb], 
        :eyes_color => [:green, :blue, :brows, :black], 
        :hair_length => [:short, :long]} 

вы можете использовать его как

  • вне самой модели, делая

    User :: ALLOWED_SETTINGS

  • внутри вашей модели (в валидаций , методы экземпляра или где угодно):

    ALLOWED_SETTINGS

+0

Привет SDP, спасибо за Ваш ответ! Где бы вы сохранили предопределенные значения? Вероятно, было бы разумно иметь их где-то в одном месте, где их можно легко модифицировать в одном месте! Не могли бы вы поместить их в какой-то отдельный класс или просто свалить их в константах внутри пользователя? Ура! – jfornoff

1

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

Если я читаю это правильно, я бы порекомендовал (и использовал) yml-файл в каталоге config/ для таких значений. Файл yml доступен для широкого доступа, и все ваши «настройки» могут находиться в одном файле. Затем они могут быть загружены в ваши модели в виде констант и сериализованы как @SDp. Тем не менее, я склонен ошибаться на стороне осторожности, особенно если подумать, что, возможно, эти «общие ценности» могут когда-нибудь понадобиться, поэтому я предпочел бы, чтобы каждый из них был как столбец на столе, а не один сериализованный стоимость. Накладные расходы не намного больше, и вы получите много дополнительных встроенных преимуществ от Rails, имеющих их отдельные столбцы.

Это, я лично использовал hstore с Postgres с большим успехом, делая то, что вы описываете. Тем не менее, причина, по которой я решил использовать hstore над отдельными столбцами, заключалась в том, что я хранили несколько разных демографических данных, в которых все демографические данные могли меняться со временем (например, некоторые ключи могли быть добавлены, и что более важно, некоторые ключи могли быть удалены.) Это звучит, как и в вашем случае, маловероятно, что вы будете удалять ключи, поскольку это основные черты, но опять же, я могу ошибаться.

TL; Я считаю, что, если у вас нет веской причины (например, регулярное добавление и/или удаление ключей/настроек), это должны быть отдельные столбцы в таблице базы данных. Если вы сильно чувствуете, что они должны храниться в базе данных, сериализованы, и вы используете Postgres, проверьте hstore.

Смежные вопросы