Быть максимально сухим в приложении Ruby on Rails

Question

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

По сути, я использую плагин attachment-fu на двух уровнях.

1. Для пользовательских аватаров в пользовательском классе.
2. Разрешить вложения файлов ( PDF и т. Д.) В системе обмена сообщениями.

Мой вопрос заключается в том, какой наилучший способ использования в этих ситуациях должен оставаться СУХОЙ , ясным и последовательным.

Ясно, что не имеет смысла определять и запускать плагин в обоих классах, но есть кое-что глубоко странное для меня (возможно, необоснованное) в том, чтобы просто идти вперед и настраивать все это в божественном классе Application.

Есть ли что-то среднее или родительский класс - путь?

Спасибо!

Answer 1

В чем проблема DRY при двойном определении параметров attachment_fu?

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

Конечно, у вас будет два объявления has_attachment, но параметры в основном будут отличаться (одно объявление для ваших аватаров, а другое для ваших PDF-файлов и т. Д.)

99,99% кода для обработки вложений будут похоронены в библиотеках attachment_fu, по умолчанию ваш код конфигурации должен быть довольно СУХИМЫМ =)

Answer 2

То, что описывает wfarr, будет наследование одной таблицы , что я сейчас и делаю в этой ситуации. У меня есть одна таблица для активов, которая содержит все необходимые столбцы attachment_fu, плюс дополнительный столбец с именем type, который будет содержать фактическое имя модели. У меня есть модель для активов и дополнительные модели для определенных типов загрузки, которые наследуются от активов:

asset.rb:

class Asset < ActiveRecord::Base
  ... attachment_fu logic ...
end

avatar.rb:

class Avatar < Asset
  ... avatar specific attachment_fu logic ...
end

pdf.rb:

class PDF < Asset
  ... PDF specific attachment_fu logic ...
end

Answer 3

Является ли поддержка "аутсорсинга" аватаром полностью Gravatar опцией? Есть некоторые плагины Rails, которые будут отображать аватары, размещенные в Gravatar. Вам, возможно, не нужно заново изобретать колесо.

Answer 4

Я бы склонялся к использованию родительского класса с подклассами для различных способов, которыми вы намерены фактически использовать вложения в своем приложении. Возможно, это не самое СУЩЕСТВЕННОЕ решение, доступное, однако оно вполне поддается логическому шаблону.

Answer 5

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

http://gist.github.com/33011

Answer 6

Не могли бы вы использовать Полиморфные ассоциации ?

Я собираюсь поразить это в своем приложении с attachment_fu, поэтому я не совсем уверен в attachment_fu, но для старой школы File Column плагин, я бы использовал Полиморфные Ассоциации.

Моя "файловая" модель будет:

    class FileUpload < ActiveRecord::Base
      belongs_to :fileable, :polymorphic => true
      file_column :name
    end

и тогда любые модели, которым требуется вложение файла, будут выглядеть так:

    class Company < ActiveRecord::Base
      has_many :file_uploads, :as => :fileable
    end

File Column больше не годится, так как он работает в Safari 3.x и больше не поддерживается. Это было мило и просто ... О, старые добрые времена ...