Ser o mais SECO possível em um aplicativo Ruby on Rails

Question

Atualmente estou usando o incrível plugin attachment-fu para um aplicativo Rails, mas como desenvolvedor novato, nunca encontrei um cenário como aquele em que me encontrei.

Essencialmente, estou usando o plugin attachment-fu em dois níveis.

1. É para avatares de usuários na classe de usuário.
2. É permitir anexos de arquivos (PDFs, etc) em um sistema de mensagens.

Minha pergunta é qual seria a melhor prática de uso nessas situações para permanecer SECO, claro e consistente.

É claro que não faria sentido definir e executar o plugin em ambas as classes, mas há algo profundamente estranho para mim (possivelmente infundado) em simplesmente seguir em frente e configurar tudo na divina classe Application.

Existe algo intermediário ou a classe pai é o caminho a seguir?

Obrigado!

Answer 1

Eu preferiria usar uma classe pai, com subclasses para as diferentes maneiras pelas quais você pretende realmente usar os anexos em seu aplicativo.Pode não ser a solução mais DRY disponível, no entanto, ela se adapta bastante bem a um padrão lógico.

Answer 2

Qual é o problema do DRY ao definir as configurações de attachment_fu duas vezes?

A menos que os arquivos sejam do mesmo tipo e armazenados no mesmo local, você não repetirá nada na configuração.

Claro, você terá duas declarações has_attachment, mas as opções serão em sua maioria diferentes (uma declaração para seus avatares e outra para seus PDFs, etc.

99,99% do código para lidar com anexos será enterrado nas bibliotecas attachment_fu, seu código de configuração deve ser bem SECO por padrão =)

Answer 3

O suporte de avatar está "terceirizando" inteiramente para Gravatar uma opção?Existem alguns plugins Rails que exibirão avatares hospedados pelo Gravatar.Talvez você não precise reinventar a roda aí.

Answer 4

O que wfarr está descrevendo seria herança de tabela única, que é o que faço atualmente nesta situação.Eu tenho uma tabela para Ativos que contém todas as colunas attachment_fu necessárias, além de uma coluna extra chamada type, que conterá o nome real do modelo.Tenho um modelo para ativos e modelos adicionais para tipos de upload específicos que herdam de ativos:

ativo.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 5

Você não poderia usar Associações Polimórficas?

Estou prestes a acertar isso no meu aplicativo com attachment_fu, então não tenho certeza sobre attachment_fu, mas para a velha escola Coluna Arquivo plugin, eu usaria associações polimórficas.

Meu modelo de "arquivo" seria:

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

e então qualquer modelo que precisasse de um anexo de arquivo seria como:

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

A coluna de arquivo não é mais boa, pois funciona no Safari 3.xe não é mais mantida.Mas foi legal e simples...Ah, os bons velhos tempos...

Answer 6

Pelo que vale, acho que Patrick Berkeley fez um bom trabalho ao lidar com vários anexos por meio do plugin Paperclip.Ele descreveu seu trabalho aqui:

http://gist.github.com/33011