CarrierWave integration
Ruby on Railsアプリケーションで画像の動的アップロードをサポートしている場合、画像はおそらく特定のモデルエンティティに添付されます。 RailsはデフォルトでモデルエンティティにActiveRecordを使用しますが、MongoidドキュメントはMongoDBベースのモデルに使用されます。 例としては、画像をPostエンティティの’picture’属性として保持したり、ユーザーエンティティの’profile_picture’属性として保持したりすることがあります。
CarrierWave gemは、画像のアップロードをモデルと統合するのに役立ちます。 デフォルトでは、CarrierWaveはローカルハードドライブに画像を保存しますが、画像の保存と操作に使用できる追加のプラグインもあります。
Cloudinary gemはCarrierWave用のプラグインを提供します。 このプラグインを使用すると、Cloudinaryの大きな利点を楽しみながら、簡単にHTMLフォームからモデルに画像をアップロードするためのCarrierWaveの利点を楽しむことがで
CarrierWaveのインストールと設定
CarrierWaveを使用してActiveRecordまたはMongoidで画像をアップロードするためのオプションの統合モジュールを使用するには、CarrierWave gemをインストールします:
gem install carrierwave
Rails3.x Gemfile:
gem 'carrierwave'gem 'cloudinary'
Rails2.x環境。rb
config.gem 'carrierwave', :version => '~> 0.4.10'config.gem 'cloudinary'
注
CarrierWave gemはCloudinary gemの前にロードする必要があります。
アップロード例
以下は、RailsプロジェクトでCarrierWaveでCloudinaryを使用することを示す短い例です。 この例では、Postモデルエンティティを使用して、各投稿に画像を添付することをサポートしています。 添付された画像は、Postエンティティの’picture’属性（列）によって管理されます。
開始するには、まずCarrierWave uploaderクラスを定義し、Cloudinaryプラグインを使用するように指示します。 詳細については、CarrierWaveのドキュメントを参照してください。
この例では、アップロードされた画像をクラウドに保存する前にPNGに変換します。 また、post_pictureタグを割り当てます。 私たちは、私たちのサイトに画像を表示するために必要な二つの追加の変換を定義します：”標準”と”サムネイル”。 ランダムに生成された一意のパブリックIDは、アップロードされた画像ごとに生成され、モデルに永続的に格納されます。
次の例では、’Post’エンティティの’short_name’属性の内容に基づいてpublic_idを明示的に定義します。
Postの’picture’属性は単なる文字列です（もちろんDB移行スクリプトが必要です）。 定義した’PictureUploader’クラスにマウントします:
class Post < ActiveRecord::Base ... mount_uploader :picture, PictureUploader ...end
投稿編集用のHTMLフォームには、画像をアップロードするためのファイルフィールドと、アップロードされた画像を失うことなくページのリロードと検証エラーをサ 以下の例は’HAML’にあります（もちろん、’ERB’を使用してまったく同じことを行うことができます’):
= form_for(:post) do |post_form| = post_form.hidden_field(:picture_cache) = post_form.file_field(:picture)
私たちのコントローラでは、標準的な方法で投稿の属性を保存または更新します。 例えば:
post.update_attributes(params)
注
ブラウザからCloudinaryに直接画像をアップロードする場合、実際の画像データではなく、署名付き識別子がコントローラに送信されます。 CloudinaryのCarrierWaveプラグインは、直接識別子をシームレスに処理し、署名を検証し、アップロードされた画像への参照を使用してモデルを更新します。
この時点で、ユーザーがサーバーにアップロードした画像はCloudinaryにアップロードされ、Cloudinaryには指定されたパブリックIDとタグも割り当てられ、PNGに変換されます。 公開IDとアップロードされた画像のバージョンは、Postエンティティの’picture’属性に格納されます。 デフォルトでは、変換はこの時点では生成されず、エンドユーザーが初めて変換にアクセスしたときにのみ生成されることに注意してください。 これは、各変換に対して’process:eager=>true’または単に’eager’を指定しない限り当てはまります。
これで、アップロードされた画像とその派生変換を表示するための標準のimage_tag呼び出しを使用でき、Cloudinary gemはリソースにアクセスするための正しい完全なURLを自:
image_tag(post.picture_url, :alt => post.short_name)image_tag(post.picture_url(:thumbnail), :width => 50, :height => 50)
カスタムおよび動的変換
Carrierwave用Cloudinaryのプラグインは、すべての標準CarrierWaveのサイズ変更とクロップオプションをサポートしています。 さらに、cloudinary_transformationメソッドを使用して、Cloudinaryでサポートされている任意のカスタム変換を適用できます。 cloudinary_transformationの呼び出しは、標準のCarrierWave resizeメソッドとcropメソッドと組み合わせて行うこともできます。 次のuploaderクラスは、カスタム変換を使用する一般的な例を示しています。
これをさらに進めて、連鎖変換を適用して、より複雑な結果を得ることができます。 これらの変換は、アップロード中に着信変換として、またはアップロード中に遅延または熱心に生成される異なるバージョンの一部として適用できます。 次のuploaderクラスには、transformationメソッドのcloudinary_transformationパラメーターを使用して適用されるこのようなチェーン変換が含まれています。
一部のウェブサイトは、同じ画像をさまざまな次元で表示するように強制するグラフィックデザインを持っています。 複数のアップローダーのバージョンを正式に定義するのは面倒です。 ビューの構築中に必要な変換を適用することで、CarrierWaveを使用してCloudinaryの動的変換を活用することができます。 CarrierWaveのバージョンに依存せずに、ビューから任意のバージョンを動的に生成できます。 これを実現するには、full_public_id属性とcl_image_tagを使用して、モデルに添付されたアップロードされた画像のクラウドベースの変換Urlを構築します。
cl_image_tag(post.picture.full_public_id, :format => "jpg", :width => 100, :height => 200, :crop => :crop, :x => 20, :y => 30, :radius => 10)
カスタム座標ベースのクロッピング
ユーザーが手動でクロッピング領域を選択できるようにする場合は、x、y座標をモデル内に永続的に保持して、元の画 次のuploaderクラスは、modelオブジェクトの属性からカスタム座標を取得します。 この例のcustom_cropメソッドは、適用する追加のCloudinary変換パラメーターのハッシュを返します。
画像のトリミングされたバージョンのみを保存する場合は、着信変換を使用できます。 この方法では、元の画像はクラウドに保存されず、トリミングされたバージョンのみが保存されます。 その後、さらに変換を使用して、トリミングされた画像のサイズを変更できます。 次の例では、カスタム座標がモデル上の一時的な属性として保持されている間に（’version’ではなく）クラス自体でprocess :custom_cropを呼び出します（永続的に格納する代わりにattr