2009-05-27 5 views
3

У меня есть хороший маленький «фото» класс, который имеет прикрепленные изображения. Когда я перехожу на страницу, чтобы отсортировать порядок фотографий, она повторяется, хотя каждая фотография устанавливает новое значение «сортировка» и сохраняет его. Все хорошо до сих пор.attachment_fu: Не перезагружать миниатюры

Проблема в том, что я заметил, что такое поведение происходит довольно медленно. Оказывается, attachment_fu перезагружает миниатюру при каждом сохранении - независимо от того, есть ли новые данные изображения для работы.

Очевидно, что эта система была продуманной, поэтому мне остается только предположить, что для этой ситуации существует условие. Как сообщить функции attachment_fu не восстанавливать миниатюры, когда это не подходит?

Спасибо, --Matchu

Edit: Я просто вспомнил, что для этой конкретной ситуации, я могу использовать update_attribute увернуться все валидации и других функции обратного вызова. Тем не менее, это не очень жизнеспособный ответ на весь большой сценарий. Что мне не хватает?

+0

Это кажется мне странным. Вы отправили сообщение в список рассылки в AttachmentFu dev? Было бы полезно получить «авторитетную» причину поведения для отправки назад для сообщества SO или внести свой патч, если это нежелательное поведение. –

ответ

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. Мне бы это понравилось, если Matchu мог поделиться патчем или фрагментом его модифицированного save_attachment? метод. Я собираюсь копаться в это сам, так как это стало проблемой для меня, и это, вероятно, будет меньше работы, чем замена attachment_fu полностью ...

Update

С контуром Matchu, в Я придумал короткое (если неэлегантное) решение, которое, похоже, работает после легких испытаний.

I modifed save_attachment? in attachment_fu/attachment_fu.rb:

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

... для проверки условий Matchu Lay out.Я не мог придумать элегантный способ сказать, были ли данные переданы вместе с методом uploaded_data = setter (если у кого-то есть лучший способ сделать это, я все уши, я все еще рубин/рельсы 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 

Надежда, что помогает, и если кто-то имеет более элегантный способ справиться, что я там делал с глобальной переменной, I» Я люблю его слышать.

+0

Мой подход был очень, очень похожим. Я сделал свой филиал в Гитубе и добавил некоторые тесты. Некоторые другие ветви втянули в обновление, но я не думаю, что главная ветка. http://github.com/matchu/attachment_fu/tree/master – Matchu

 Смежные вопросы

  • Нет связанных вопросов^_^