In einer Ruby on Rails-App so trocken wie möglich sein

Question

Ich verwende derzeit das tolle Anhang-Fu-Plugin für eine Rails-App, aber als unerfahrener Entwickler habe ich noch nie ein Szenario wie das erlebt, in dem ich mich befand.

Im Wesentlichen verwende ich das Anhang-Fu-Plugin auf zwei Ebenen.

1. Ist für Benutzeravatare in der Benutzerklasse.
2. Soll Dateianhänge zulassen (PDFs, usw.) in einem Nachrichtensystem.

Meine Frage ist, welche Vorgehensweise in diesen Situationen am besten wäre TROCKEN, klar und konsistent.

Natürlich würde es keinen Sinn machen, das Plugin in beiden Klassen zu definieren und auszuführen, aber es ist für mich zutiefst seltsam (möglicherweise unbegründet), einfach so weiterzumachen und alles in der göttlichen Application-Klasse einzurichten.

Gibt es etwas dazwischen oder ist die Elternklasse der richtige Weg?

Danke!

Answer 1

Ich würde zur Verwendung einer übergeordneten Klasse tendieren, mit Unterklassen für die verschiedenen Arten, wie Sie die Anhänge in Ihrer Anwendung tatsächlich verwenden möchten.Es ist vielleicht nicht die trockenste verfügbare Lösung, eignet sich jedoch recht gut für ein logisches Muster.

Answer 2

Was ist das Problem mit der doppelten Definition der attachment_fu-Einstellungen?

Sofern die Dateien nicht vom gleichen Typ sind und am gleichen Ort gespeichert sind, werden Sie in der Konfiguration nichts wiederholen.

Sicher, Sie haben zwei has_attachment-Deklarationen, aber die Optionen unterscheiden sich größtenteils (eine Deklaration für Ihre Avatare und die andere für Ihre PDFs usw.).

99,99 % des Codes zur Handhabung von Anhängen werden in den attachment_fu-Bibliotheken vergraben, Ihr Konfigurationscode sollte standardmäßig ziemlich trocken sein =)

Answer 3

Ist die Avatar-Unterstützung vollständig auszulagern? Gravatar eine Option?Es gibt einige Rails-Plugins, die von Gravatar gehostete Avatare anzeigen.Möglicherweise müssen Sie das Rad dort nicht neu erfinden.

Answer 4

Was wfarr beschreibt, wäre Einzeltabellenvererbung, was ich derzeit in dieser Situation mache.Ich habe eine Tabelle für Assets, die alle erforderlichen attachment_fu-Spalten sowie eine zusätzliche Spalte namens „type“ enthält, die den tatsächlichen Modellnamen enthält.Ich habe ein Modell für Assets und zusätzliche Modelle für bestimmte Upload-Typen, die von Assets erben:

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 5

Könntest du nicht benutzen Polymorphe Assoziationen?

Ich bin dabei, dies in meiner App mit attachment_fu zu erreichen, daher bin ich mir bei attachment_fu nicht ganz sicher, aber für die alte Schule Dateispalte Plugin würde ich Polymorphic Associations verwenden.

Mein „Datei“-Modell wäre:

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

und dann würden alle Modelle, die einen Dateianhang benötigen, wie folgt aussehen:

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

File Column funktioniert nicht mehr, da es unter Safari 3.x funktioniert und nicht mehr gewartet wird.Es war aber schön und einfach...Ach, die guten alten Zeiten...

Answer 6

Ich denke, Patrick Berkeley hat bei der Handhabung mehrerer Anhänge über das Paperclip-Plugin gute Arbeit geleistet.Er hat seine Arbeit hier beschrieben:

http://gist.github.com/33011