views:

157

answers:

1

On my application I've several things with attachments on them, using paperclip.

  • Clients have one logo.
  • Stores can have one or more pictures. These pictures, in addition, can have other information such as the date in which they were taken.
  • Products can have one or more pictures of them, categorized (from the font, from the back, etc).

For now, each one of my Models has its own "paperclip-fields" (Client has_attached_file) or has_many models that have attached files (Store has_many StorePictures, Product has_many ProductPictures)

My client has also told me that in the future we might be adding more attachments to the system (i.e. pdf documents for the clients to download).

My application has a rather complex authorization system implemented with declarative_authorization. One can not, for example, download pictures from a product he's not allowed to 'see'.

I'm considering re-factoring my code so I can have a generic "Attachment" model. So any model can has_many :attachments.

With this context, does it sound like a good idea? Or should I continue making Foos and FooPictures?

+2  A: 

I've found there are often cases where a generic Attachment class is a whole lot easier to manage than independent attachments on various other types of records. The only down-side to the simple Attachment approach is that the thumbnails that need to be produced are defined for all possible attachments simultaneously instead of on a case-by-case basis.

A hybrid approach that allows for more flexibility is to create a STI-based Attachment table by including a 'type' column and making use-specific subclasses such as ProductAttachment that defines specific styles.

tadman
Thanks for your answer. I finally ended up not refactoring, because of the extra fields needed in some places. Doing STI would have helped there, but the involved work was just not worth it.
egarcia