2009-05-27 84 views
3

我有一个很好的附加图像的“照片”类。当我去页面排序照片的顺序时,它会遍历每张照片,设置新的“排序”值并保存。迄今为止都很好。attachment_fu:不要重新加载缩略图

问题是,我注意到这种行为相当缓慢。原来,attachment_fu会在每次保存时重新加载缩略图 - 无论是否有新的图像数据可用。

很明显,这个系统已经经过深思熟虑,所以我只能假设为这种情况提供了一个规定。如何告诉attachment_fu在不适合时重新生成缩略图?

感谢,--Matchu

编辑:我只记得,对于这种特殊的情况,我可以用update_attribute闪避所有的验证等回调。但是,这对于整个大场景来说并不是一个可行的答案。我错过了什么?

+0

这对我来说似乎很陌生。你有没有在AttachmentFu开发者邮件列表上发布它?获得一个“权威”的理由可能会有助于将该行为发回SO社区,或者如果它是不理想的行为,则可以提供补丁。 – 2009-05-29 04:35:02

回答

3

加入并攻击了attachment_fu一下,并重写了save_attachment?行为。好看多了,我增加了一些新的情况:除了一个临时文件存在,执行下列操作之一必须是真实的:

  1. 没有文件的图像已经存在(使用full_filename属性)。
  2. 使用uploaded_data=方法明确更新图像数据。
  3. 图片是一个缩略图。

它通过了所有三个测试用例 - 新的照片上传,编辑照片图像和编辑非图像照片数据 - 但我还没有真正在野外测试过。我可能不得不做一些修复;我们会看到会发生什么。

0

唯一我已经看到了这个话题比较有用的线程是在这里:

http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/709d97e06b373786

我觉得Matchu的解决方案可能是正确的与attachment_fu代码的快速审查。如果可以分享补丁或修改后的save_attachment片段,我会喜欢它吗?方法。我即将挖成这个我自己,因为这已经成为我的问题,它可能会比完全取代attachment_fu工作量少...

更新

随着Matchu的轮廓,我想出了一个简短的(如果不够优雅的)解决方案,似乎在轻度测试后就可以工作。

我修改了save_attachment?在attachment_fu/attachment_fu.rb中:

def save_attachment? 
    return false unless (thumbnail || !full_filename || @active_upload) #added 
    File.file?(temp_path.to_s) 
end 

...检查条件是否正确。我无法想出一个优雅的方式来判断数据是否已经传递到uploaded_data = setter方法(如果有人有更好的方法来做到这一点,我都耳熟能详;我仍然是一个ruby/rails noob ),所以我还添加了一行到uploaded_data =设置全局变量@active_upload:

def uploaded_data=(file_data) 
    return nil if file_data.nil? || file_data.size == 0 
    self.content_type = file_data.content_type 
    self.filename  = file_data.original_filename if respond_to?(:filename) 
    @active_upload=true # added 
    if file_data.is_a?(StringIO) 
    file_data.rewind 
    self.temp_data = file_data.read 
    else 
    self.temp_path = file_data 
    end 
end 

希望帮助,如果任何人有一个更优雅的方式来处理我与全局变量确实存在,我d爱听到它。

+0

我的方法非常非常相似。我在Github上创建了自己的分支,并添加了一些测试。更新中一些其他分支,但我认为主要分支没有。 http://github.com/matchu/attachment_fu/tree/master – Matchu 2009-07-14 02:44:07