views:

138

answers:

1

First off, we have this namespaced/sti'd structure for our different types of 'Media'

Media< Ar::Base
Media::Local < Media
Media::Local::Image < Media::Local
Media::Local::Csv < Media::Local

etc... etc..

This is excellent since a user can have many media, and how we display each piece of media is based on the class name and a co-responding partial.

But what if we have some Csv's that need to be secure? That is, they can't reside inside of public. I really hate the idea of branching Media again and doing something like this:

Media::Secure < Media
Media::Secure::Image < Media::Secure
Media::NotSecure < Media
Media::NotSecure::Image < Media::NotSecure

...where Secure and NotSecure would have different params passed to has_attached_file.

Now there are two classes that represent Image and it makes my view/helper system that much more complicated -- not to mention it feels very obtuse.

What I would really like to do is be able to change where certain Paperclip::Attachment objects get saved before they get saved (e.g. anything uploaded through foo_secure_action) -- but I can't seem to make this work. Paperclip::Attachment has an @options hash with :path and :url, but changing those before it is saved doesn't have an effect on where it actually gets set. Even if this is possible, I'm not sure if it would have further consequences...

I'm open to alternative ideas for structuring this data, but for the moment I like the idea of using STI for this situation.

A: 

I can do this with Paperclip.interpolates in an intializer.

crankharder