Frage

Ich habe eine schöne kleine "Fotos" -Klasse, in der Bilder angehängt sind. Wenn ich zur Seite gehe, um die Reihenfolge der Fotos zu sortieren, iteriert sie durch jedes Foto, legt den neuen "Sortier" -Werte fest und speichert sie. Alles gut bisher.

Das Problem ist, ich habe bemerkt, dass dieses Verhalten ziemlich langsam ist. Es stellt sich heraus, dass Attachment_FU das Miniaturbild bei jedem Speichern neu lädt - unabhängig davon, ob es neue Bilddaten gibt oder nicht.

Offensichtlich war dieses System gut durchdacht, daher werde ich nur davon ausgehen, dass eine Bestimmung für diese Situation vorhanden ist. Wie sage ich bei Attachment_FU, dass ich die Miniaturansichten nicht regenerieren soll, wenn es nicht angemessen ist?

Vielen Dank, -matchu

Bearbeiten: Ich erinnerte mich nur daran, dass ich für diese bestimmte Situation Update_attribute verwenden kann, um allen Validierungen und anderen Rückernständen auszuweichen. Dies ist jedoch keine wirklich praktikable Antwort auf das ganze große Szenario. Was vermisse ich?

War es hilfreich?

Lösung

Ging hinein und gehackte Attachment_fu ein bisschen und schrieb das neu um save_attachment? Verhalten. Ziemlich genau, ich habe einige neue Bedingungen hinzugefügt: Zusätzlich zu einer vorhandenen TEMP -Datei muss eine der folgenden Bedingungen wahr sein:

  1. Es gibt keine Datei für das Bild bereits (mit dem full_filename Attribut).
  2. Die Bilddaten wurden explizit mit dem aktualisiert uploaded_data= Methode.
  3. Das Bild ist ein Miniaturbild.

Es gibt alle drei Testfälle - neue Foto -Uploads, Fotobilder bearbeiten und nicht -image -Fotodaten bearbeiten -, aber ich habe dies in freier Wildbahn noch nicht wirklich getestet. Ich muss wahrscheinlich ein paar Korrekturen vornehmen. mal sehen was passiert.

Andere Tipps

Der einzig mäßig nützliche Thread, den ich zu diesem Thema gesehen habe, ist hier:

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

Ich denke, die Lösung von Matchu ist wahrscheinlich die richtige mit einer kurzen Überprüfung des Codes für Attachment_FU. Ich würde es lieben, wenn Matchu einen Patch oder einen Ausschnitt seines modifizierten Save_attachment teilen könnte? Methode. Ich bin im Begriff, alleine darauf einzugehen, da dies für mich zu einem Problem geworden ist und es wahrscheinlich weniger Arbeit sein wird als das Ersetzen von Attemment_FU völlig ...

Aktualisieren

Mit Matchu's Umriss habe ich eine kurze (wenn auch unelegante) Lösung entwickelt, die nach Lichttests zu funktionieren scheint.

Ich modifizierte Save_attachment? In Attemment_FU/Attachment_FU.RB:

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

... um die Bedingungen zu überprüfen, die Matchu ausgelegt sind. Ich konnte mich nicht elegant erkennen, um festzustellen, ob Daten an die Methode uploadd_data = setzter weitergegeben wurden (wenn jemand eine bessere Möglichkeit hat, bin ich alle Ohren; ich bin immer noch ein Rubin/Rails Noob ) Ich habe also auch eine Zeile zu uploaded_data = hinzugefügt, um die globale Variable @Active_Upload festzulegen:

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

Ich hoffe, das hilft, und wenn jemand eine elegantere Möglichkeit hat, das mit dem zu behandeln, was ich dort mit der globalen Variablen gemacht habe, würde ich es gerne hören.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top