17

私は、Django 用のさまざまなサムネイル アプリについて読み、試してきました。要件は次のとおりです。

  • 生成されたすべてのサムネイルは、元の画像とは別の S3 バケットに保存する必要があります (別のストレージ クラスなど)。

  • 画像インスタンスが削除されると、元の画像ファイルと生成されたすべてのサムネイルも削除する必要があります

  • 費用のかかる非効率性を最小限に抑えます。DRF でシリアル化するサムネイルの URL を取得する場合、S3 バケットを調べて毎回存在するかどうかを確認する必要はありません。

VersatileImageField は最初の要件を満たしていません。ImageKit は 2 番目の要件を満たしていません。3 番目の要件は、私が最も混乱しているところです。ベスト プラクティスについて自分自身に情報を提供しようとしていますが、情報が断片的であり、これまでに学んだことに基づいて決定を下す自信がありません。

私が読んだことから、最も効率的な動作は次のようになるというのが私の印象です。

  • 保存するとすぐにサムネイルを生成し、常に存在すると仮定します
  • サムネイルにアクセスするには、元の画像のファイル名とサムネイルのサイズ/品質に基づいて URL を生成します。
  • post_delete は、すべてのサムネイルと元のファイルを削除します

easy-thumbnails と sorl-thumbnails が取るアプローチの違い (上記で簡単に説明したプロセスと一致する場合、またはより効率的なものがある場合)、および利点/欠点について学ぶことに最も興味があります。それぞれの方法論で。

4

2 に答える 2

0

これが役立つかどうかはわかりませんが、私は過去に簡単なサムネイルを使用したことがあり、少し設定すれば、求めているすべてのことを実行できると確信しています. 保存機能は設定を気にしないため、保存機能を使用して設定するのは少し難しいですが、不可能ではありません。問題を引き起こす主な原因は、サムネイル オプションにアクセスして使用するには、[保存して編集を続行] を使用する必要があることです。保存時に作成されるため、まだ作成していない場合は、そうするまで表示されません。

def save()
    found_id = self.id
        super(Team, self).save(*args, **kwargs)
        if self.image and found_id is None and self.original_image_width and self.original_image_height:
            self.image = get_thumbnailer(self.image).get_thumbnail({
                'size': (self.original_image_width, self.original_image_height)
            }).name
        super(Team, self).save(*args, **kwargs)
于 2016-03-04T16:36:25.483 に答える