I''m poring through the Dragonfly source code right now, trying to get a handle on how to apply the following technique there: Client uploads a Zip archive containing N images, PDF files, text files, etc. When that file arrives at the server, but before it is stored as an attachment to the current object, the Zip is burst open, contents are iterated over, and each contained file is saved as a new Dragonfly attachment. The original Zip is discarded. I have found an article from 2008 that shows in detail how to do this with Attachment Fu. But my understanding is that a: attachment_fu isn''t up to date with Rails 3, let alone 3.1, and b: it uses a discrete AR model for the saved file, rather than the Dragonfly approach, which seems more indirect, or at least, doesn''t present a clean target for extension. Has anyone looked at this problem, and can anyone share any pointers? I''d really like to stick with Dragonfly, because it has so many benefits on the display side of things with on-the-fly resizing and cropping possible. I can already see in my mind how I would use Paperclip to do this, that actually seems quite straightforward by comparison. So if there''s a way to use Paperclip for the uploads and Dragonfly for the display later, I''d be curious to hear about that instead. Thanks in advance, Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Il giorno giovedì 15 settembre 2011 15:26:22 UTC+2, Walter Lee Davis ha scritto:> I''m poring through the Dragonfly source code right now, trying to get a handle on how to apply the following technique there: > > Client uploads a Zip archive containing N images, PDF files, text files, etc. When that file arrives at the server, but before it is stored as an attachment to the current object, the Zip is burst open, contents are iterated over, and each contained file is saved as a new Dragonfly attachment. The original Zip is discarded. > > I have found an article from 2008 that shows in detail how to do this with Attachment Fu. But my understanding is that a: attachment_fu isn''t up to date with Rails 3, let alone 3.1, and b: it uses a discrete AR model for the saved file, rather than the Dragonfly approach, which seems more indirect, or at least, doesn''t present a clean target for extension. > > Has anyone looked at this problem, and can anyone share any pointers? I''d really like to stick with Dragonfly, because it has so many benefits on the display side of things with on-the-fly resizing and cropping possible. > > I can already see in my mind how I would use Paperclip to do this, that actually seems quite straightforward by comparison. So if there''s a way to use Paperclip for the uploads and Dragonfly for the display later, I''d be curious to hear about that instead. > > Thanks in advance, > > WalterHi Walter, do you ever solved this? Thank you! enricostn -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/yfYTetS-2R0J. For more options, visit https://groups.google.com/groups/opt_out.
Yes I did. My solution is bound to my application, but here it is, copied and
pasted from the working app:
#source.rb (the model that the Dragonfly attachment lives in)
file_accessor :file do
storage_path{|f| "titles/#{title_id}/#{f.name}"}
end
belongs_to :title
after_create :unpack
def unpack
if zip?
source = File.join(file.app.datastore.configuration[:root_path],file_uid)
zipfile = Zip::ZipFile.open(source)
zipfile.each do |entry|
if entry.file? && ! File.basename(entry.name).match(/^\./)
if entry.name.downcase.match(/\.(pdf|mov|mp3|mp4|m4a|xml)$/)
extracted_file = zipfile.read(entry.name)
new_file = self.title.sources.build
new_file.file = extracted_file
new_file.file_name = File.basename(entry.name)
new_file.save!
end
end
end
self.destroy
end
end
def zip?
file.format && file.format.to_s.include?(''zip'')
end
I am pretty sure I double-posted this question, and my reply that all was well
was in the other thread. Please let me know if this makes sense, or if you need
more explanation. It may be too concrete to my own needs, but I hope it gives
you a start.
Walter
On Aug 7, 2012, at 5:40 AM, enrico stano wrote:
> Il giorno giovedì 15 settembre 2011 15:26:22 UTC+2, Walter Lee Davis ha
scritto:
>> I''m poring through the Dragonfly source code right now, trying
to get a handle on how to apply the following technique there:
>>
>> Client uploads a Zip archive containing N images, PDF files, text
files, etc. When that file arrives at the server, but before it is stored as an
attachment to the current object, the Zip is burst open, contents are iterated
over, and each contained file is saved as a new Dragonfly attachment. The
original Zip is discarded.
>>
>> I have found an article from 2008 that shows in detail how to do this
with Attachment Fu. But my understanding is that a: attachment_fu isn''t
up to date with Rails 3, let alone 3.1, and b: it uses a discrete AR model for
the saved file, rather than the Dragonfly approach, which seems more indirect,
or at least, doesn''t present a clean target for extension.
>>
>> Has anyone looked at this problem, and can anyone share any pointers?
I''d really like to stick with Dragonfly, because it has so many
benefits on the display side of things with on-the-fly resizing and cropping
possible.
>>
>> I can already see in my mind how I would use Paperclip to do this, that
actually seems quite straightforward by comparison. So if there''s a way
to use Paperclip for the uploads and Dragonfly for the display later,
I''d be curious to hear about that instead.
>>
>> Thanks in advance,
>>
>> Walter
>
> Hi Walter,
>
> do you ever solved this?
>
> Thank you!
>
> enricostn
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-talk/-/yfYTetS-2R0J.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.