I wasn’t sure where to email this request, so I am hoping the author of
file_column actually sees this. I was wondering if there were any plans
to
allow some configurability in the file_column plugin. By configurability
I
mean allowing the developer to define which table column is used as the
unique identifier when creating image folders. Right now it seems like
it
uses the ID of the table. It would be nice to allow a different field
(say a
username in a Users table.) Along the same lines, it would also be very
nice
if the developer could change the location where file_column stores the
images. Say instead of using the model name, I want to store everything
in
$RAILS_ROOT/public/assets/profiles/
if the developer could change the location where file_column stores the
images. Say instead of using the model name, I want to store everything in
$RAILS_ROOT/public/assets/profiles/
You can set the storage base path with the :store_dir option:
file_column :image, :store_dir => “foobar”
As for the path prefix, you could dynamically redefine the method
FileColumn::PermanentUploadedFile#relative_path_prefix somewhere in
your application code. The default implementation is pretty
straight-forward
def relative_path_prefix @instance.id.to_s
end
so just replace ‘id’ with ‘username’
Sebastian, would it be possible to provide a callback hook for setting
the storage path dynamically?
In my current project I have Mugshot AR instances that are part of
Collection AR instances. The Image AR has one file_column field and a
few vanilla fields. It would be great if I could easily layout my
storage so that my images would be saved in subdirectories of the
collections to which they belong, so that they end up stored somewhat
like this (disregarding any sanitychecks)
Any tips on “dynamically redefining” a method? I’m pretty new to
Ruby/Rails
and I’m not sure how to redefine the relatve_path_prefix method. Where
in my
code do I put this anyway? In the lib folder as a new file or I can
pretty
much put it anywhere?
The problem is, my image is actually not in my User model, but in my
Profile
model. Each User has_many Profiles and Profile belongs_to User. So if @intance is the Profile object, then I can’t do @intance.login.to_s,
since
login is a field in the User object.
Ok, I kinda figured out what I need to do, here is my code:
module FileColumn
class PermanentUploadedFile
def relative_path_prefix
user = User.find(@instance.user_id)
user.login.to_s
end
end
end
So now it is using the User.login as the relative_path_prefix, but some
odd
reason the actual folder isn’t being created. It’s still creating the
folder
using the @instance.idhttp://instance.id. I’m guessing I need to
override
another method? Any ideas anyone? I’ll keep looking through the code to
try
and figure out and i’ll post what I find here and on the Wiki.
I found the other bit of code that needs to be changed. It is the
initialize
method. I simply made an exact copy of it in my environment.rb right
above
my redefined relative_path_prefix method and simple changed the @dir
variable to my User.login. So now it looks like this:
def initialize(*args)
super *args
user = User.find(@instance.user_id) # new code @dir = File.join(store_dir, user.login.to_s) # changed code
… rest of code
end
Not sure if this the best way to do it since I am not a Ruby expert, but
it
seems to work. If anyone can suggest “cleaner” or more efficient code,
I’d
be very geatful.
thanks for sharing your experience with using/modifying file_column.
Since the feature has been requested has been somebody else as well I
will add it to my todo list. So far, your changes look pretty sane to
me.
shouldn’t be too hard. BaseUploadedFile has a store_dir method, that
just returns a value from the @options hash right now. The
straightforward change would be to check, if a callback is defined
somewhere in the options and call this instead. If you implement it
yourself and send me a patch including some tests I will be happy to
include it.
Sebastian
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.