Быть максимально СУХИМ в приложении Ruby on Rails

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

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

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

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

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

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

Спасибо!


ruby ruby-on-rails model-view-controller attachment-fu
person btw    schedule 21.08.2008    source источник

Ответы (6)


arrow_upward
1
arrow_downward

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

person wfarr    schedule 21.08.2008

arrow_upward
3
arrow_downward

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

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

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

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

person Dave Smylie    schedule 17.09.2008

arrow_upward
2
arrow_downward

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

person John Topley    schedule 21.08.2008

arrow_upward
2
arrow_downward

Wfarr описывает наследование одной таблицы, что я сейчас и делаю в этой ситуации. У меня есть одна таблица для Assets, которая содержит все необходимые столбцы 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
person Zach    schedule 17.09.2008

arrow_upward
0
arrow_downward

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

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

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

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

а затем любые модели, которым требовалось прикрепление файла, были бы такими:

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

Столбец файлов больше не подходит, так как он работает в Safari 3.x и больше не поддерживается. Хотя все было красиво и просто ... Ах, старые добрые времена ...

person Dan Harper    schedule 17.09.2008

arrow_upward
0
arrow_downward

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

http://gist.github.com/33011

person The Pied Pipes    schedule 23.01.2009