Вопрос

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

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

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

Спасибо, -Матчо

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

Это было полезно?

Решение

Вошел и немного взломал attlement_fu и переписал save_attachment? поведение. В значительной степени я добавил несколько новых условий: в дополнение к существующему временному файлу, один из следующих должен быть правдой:

  1. Нет файла для изображения уже существует (используя full_filename атрибут).
  2. Данные изображения были явно обновлены с помощью uploaded_data= метод
  3. Изображение - миниатюра.

Он проходит все три тестовых случая - новые загрузки фотографий, редактирование фото изображений и редактирование данных с фотографиями без изображения - но я еще не проверял это в дикой природе. Мне, вероятно, придется сделать несколько исправлений; Посмотрим, что произойдет.

Другие советы

Единственный умеренно полезный поток, который я видел на этой теме, здесь:

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

Я думаю, что решение Matchu, вероятно, является правильным с быстрым обзором кода Attachment_fu. Я бы хотел, если бы Matchu мог поделиться патчем или фрагментом его модифицированного save_attachment? метод Я собираюсь покопаться в этом самостоятельно, так как это стало проблемой для меня, и это, вероятно, будет меньше работы, чем замена Attachment_fu полностью ...

Обновлять

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

Я модифицировал save_attachment? в ATTHAMENT_FU/ATTHARMENT_FU.RB:

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

... Чтобы проверить условия, выложенные. Я не мог придумать элегантный способ сказать, были ли данные переданы методу upladed_data = setter (если у кого -то есть лучший способ сделать это, я все уши; я все еще рубин/рельс Нуб ), поэтому я также добавил строку в uploaded_data = для установки глобальной переменной @acate_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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top