我目前正在为Rails应用程序使用很棒的附件插件，但是作为新手开发人员，我从未遇到过像我自己那样的情况。

本质上，我在两个级别上使用attachment-fu插件。

• 用于用户类中的用户化身。
• 用于允许邮件系统中的文件附件(PDF等)。

我的问题是，在这种情况下保持DRY清晰，一致的最佳用法是什么？

显然，在这两个类中定义和执行插件都是没有意义的，但是对于我而言，继续前进并将其全部设置在虔诚的Application类中，这是一件令我深感奇怪的事情(可能毫无根据)。

两者之间有什么关系吗，还是父类是路要走？

谢谢！

解决方案

回答

"外包"虚拟形象是否完全支持Gravatar？有一些Rails插件可以显示Gravatar托管的头像。我们可能不需要在那里重新发明轮子。

回答

我倾向于使用父类，通过子类化我们打算在应用程序中实际使用附件的不同方式。它可能不是可用的DRYest解决方案，但是，它很适合于逻辑模式。

回答

两次定义attachment_fu设置的DRY问题是什么？

除非文件的类型相同且存储在相同的位置，否则我们将不会在配置中重复任何操作。

当然，我们将有两个has_attachment声明，但是选项将大不相同(一个用于化身的声明，另一个用于pdf等的声明。

99.99％的用于处理附件的代码将被掩埋在attachment_fu库中，默认情况下，配置代码应为DRY漂亮=

回答

我们不能使用多态关联吗？

我将在我的应用程序中使用附件_fu来实现这一目标，因此我不确定在附件_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

File Column不再适用，因为它在Safari 3.x上无法使用，并且不再维护。虽然很好，却很简单...啊，过去的美好时光...

回答

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

回答

对于它的价值，我认为Patrick Berkeley在通过Paperclip插件处理多个附件方面做得很好。他在这里概述了他的工作：

http://gist.github.com/33011