Essere il più DRY possibile in un'app Ruby on Rails

Question

Attualmente sto utilizzando il fantastico plug-in attach-fu per un'app Rails, ma come sviluppatore alle prime armi non ho mai incontrato uno scenario come quello in cui mi sono trovato.

Essenzialmente, sto utilizzando il plugin attach-fu su due livelli.

1. È per gli avatar utente nella classe utente.
2. È consentire gli allegati di file (PDF, ecc.) in un sistema di messaggistica.

La mia domanda è quale sarebbe la migliore pratica d'uso in queste situazioni ASCIUTTO, chiaro e coerente.

Chiaramente non avrebbe senso definire ed eseguire il plugin in entrambe le classi, ma c'è qualcosa di profondamente strano per me (forse infondato) nell'andare avanti e impostare tutto nella divina classe Application.

C'è qualcosa nel mezzo o la classe madre è la strada da percorrere?

Grazie!

Answer 1

Io propenderei per l'utilizzo di una classe genitore, con sottoclassi per i diversi modi in cui intendi utilizzare effettivamente gli allegati nella tua applicazione.Potrebbe non essere la soluzione più DRY disponibile, tuttavia si presta piuttosto bene a uno schema logico.

Answer 2

Qual è il problema DRY con la definizione delle impostazioni attach_fu due volte?

A meno che i file non siano dello stesso tipo e non siano archiviati nello stesso posto, non ripeterai nulla nella configurazione.

Certo, avrai due dichiarazioni has_attachment, ma le opzioni saranno per lo più diverse (una dichiarazione per i tuoi avatar e l'altra per i tuoi pdf ecc.

Il 99,99% del codice per gestire gli allegati sarà sepolto nelle librerie attach_fu, il tuo codice di configurazione dovrebbe essere piuttosto DRY per impostazione predefinita =)

Answer 3

Il supporto avatar è "esternalizzato" interamente Gravatar un opzione?Ci sono alcuni plugin Rails che mostreranno gli avatar ospitati da Gravatar.Potrebbe non essere necessario reinventare la ruota lì.

Answer 4

Ciò che wfarr sta descrivendo sarebbe ereditarietà di una singola tabella, che è ciò che faccio attualmente in questa situazione.Ho una tabella per Assets che contiene tutte le colonne attach_fu necessarie, più una colonna extra chiamata type, che conterrà il nome effettivo del modello.Ho un modello per le risorse e modelli aggiuntivi per tipi di caricamento specifici che ereditano dalle risorse:

risorsa.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

Non potresti usare Associazioni polimorfiche?

Sto per inserirlo nella mia app con attach_fu, quindi non sono esattamente sicuro di attach_fu, ma per la vecchia scuola Colonna File plugin, utilizzerei Associazioni Polimorfiche.

Il mio modello "file" sarebbe:

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

e quindi tutti i modelli che necessitano di un file allegato sarebbero come:

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

La colonna File non va più bene poiché funziona su Safari 3.x e non viene più mantenuta.E' stato carino e semplice però...Ah, i bei vecchi tempi...

Answer 6

Per quello che vale, penso che Patrick Berkeley abbia fatto un buon lavoro gestendo più allegati tramite il plugin Paperclip.Ha descritto il suo lavoro qui:

http://gist.github.com/33011