CarrierWave integration

Se si supporta il caricamento dinamico delle immagini nell’applicazione Ruby on Rails, le immagini sono probabilmente collegate a una determinata entità del modello. Rails utilizza ActiveRecord per le entità del modello per impostazione predefinita, mentre i documenti Mongoid vengono utilizzati per un modello basato su MongoDB. Gli esempi possono includere il mantenimento dell’immagine come attributo ‘picture’ di un’entità Post o come attributo ‘profile_picture’ di un’entità Utente.

La gemma CarrierWave può essere utile per integrare i caricamenti di immagini con il modello. Per impostazione predefinita, CarrierWave memorizza le immagini sul disco rigido locale, ma ha anche plugin aggiuntivi disponibili per la memorizzazione e la manipolazione delle immagini.

La gemma Cloudinary fornisce un plugin per CarrierWave. L’utilizzo di questo plugin consente di godere dei vantaggi di CarrierWave per caricare facilmente le immagini da moduli HTML al modello, mentre godendo i grandi vantaggi di Cloudinary: le immagini caricate vengono memorizzati nel cloud, trasformati e manipolati nel cloud, e consegnati automaticamente attraverso un CDN.

CarrierWave installazione e setup

Per utilizzare l’opzionale modulo di integrazione per il caricamento delle immagini con ActiveRecord o Mongoid utilizzando CarrierWave, installare il CarrierWave gemma:

gem install carrierwave

Rails 3.x File gem:

gem 'carrierwave'gem 'cloudinary'

Rotaie 2.ambiente x.rb

config.gem 'carrierwave', :version => '~> 0.4.10'config.gem 'cloudinary'

Esempi di caricamento

Di seguito è riportato un breve esempio che dimostra l’utilizzo di Cloudinary con CarrierWave nel progetto Rails. In questo esempio, usiamo l’entità del modello Post per supportare il collegamento di un’immagine a ciascun post. Le immagini allegate sono gestite dall’attributo’ picture ‘ (colonna) dell’entità Post.

Per iniziare, prima definire una classe CarrierWave uploader e dirgli di utilizzare il plugin Cloudinary. Per i dettagli, vedere la documentazione CarrierWave.

In questo esempio, convertiremo l’immagine caricata in un PNG prima di memorizzarla nel cloud. Gli assegneremo anche il tag post_picture. Definiamo due trasformazioni aggiuntive necessarie per la visualizzazione dell’immagine nel nostro sito: ‘standard’ e ‘thumbnail’. Un ID pubblico univoco generato casualmente viene generato per ogni immagine caricata e memorizzato in modo persistente nel modello.

Nell’esempio seguente, definiamo esplicitamente un public_id in base al contenuto dell’attributo ‘short_name’ dell’entità ‘Post’.

L’attributo’ picture ‘ di Post è semplicemente una stringa (ovviamente è necessario uno script di migrazione DB). Lo montiamo alla classe ‘PictureUploader’ che abbiamo appena definito:

class Post < ActiveRecord::Base ... mount_uploader :picture, PictureUploader ...end

Nel nostro modulo HTML per la modifica post, aggiungiamo un campo File per caricare l’immagine e anche un campo nascosto ‘cache’ per supportare gli errori di ricaricamento e convalida della pagina senza perdere l’immagine caricata. L’esempio seguente è in ‘HAML’ (ovviamente puoi fare esattamente lo stesso usando ‘ERB’):

= form_for(:post) do |post_form| = post_form.hidden_field(:picture_cache) = post_form.file_field(:picture)

Nel nostro controller, salviamo o aggiorniamo gli attributi del post nel modo standard. Biru:

post.update_attributes(params)

A questo punto, l’immagine caricata dall’utente sul server viene caricata su Cloudinary, che ha anche assegnato l’ID pubblico e il tag specificati e lo converte in PNG. L’ID pubblico insieme alla versione dell’immagine caricata vengono memorizzati nell’attributo’ picture ‘ della nostra entità Post. Si noti che per impostazione predefinita le trasformazioni non vengono generate a questo punto; vengono generate solo quando un utente finale vi accede per la prima volta. Questo è vero a meno che non si specifichi ‘process :eager => true’ o semplicemente ‘eager’ per ogni trasformazione.

Ora è possibile utilizzare standard image_tag chiamate per visualizzare le immagini caricate e loro derivati trasformazioni e la Cloudinary gemma genera automaticamente il corretto URL completo per l’accesso a risorse:

image_tag(post.picture_url, :alt => post.short_name)image_tag(post.picture_url(:thumbnail), :width => 50, :height => 50)

Personalizzato e dinamico trasformazioni

Cloudinary plugin per CarrierWave supporta tutti gli standard di CarrierWave ridimensionare e ritagliare le opzioni. Inoltre, è possibile applicare qualsiasi trasformazione personalizzata supportata da Cloudinary utilizzando il metodo cloudinary_transformation. La chiamata cloudinary_transformation può essere eseguita anche in combinazione con i metodi standard CarrierWave resize e crop. La seguente classe uploader mostra un esempio comune di utilizzo di trasformazioni personalizzate:

È possibile prendere questo ulteriore e applicare trasformazioni concatenate per ottenere risultati più complessi. Queste trasformazioni possono essere applicate come trasformazione in entrata durante il caricamento o come parte delle diverse versioni generate pigramente o avidamente durante il caricamento. La seguente classe uploader include tali trasformazioni concatenate applicate utilizzando il parametro transformation del metodo cloudinary_transformation.

Alcuni siti web hanno un design grafico che li costringe a visualizzare le stesse immagini in molte dimensioni diverse. Definire formalmente più versioni di uploader può essere una seccatura. È comunque possibile utilizzare CarrierWave e sfruttare le trasformazioni dinamiche di Cloudinary applicando le trasformazioni desiderate durante la creazione della vista. Qualsiasi versione può essere generata dinamicamente dalla tua vista senza alcuna dipendenza dalle versioni CarrierWave. A tale scopo, utilizzare l’attributo full_public_id con cl_image_tag per creare URL di trasformazione basati su cloud per le immagini caricate associate al modello.

cl_image_tag(post.picture.full_public_id, :format => "jpg", :width => 100, :height => 200, :crop => :crop, :x => 20, :y => 30, :radius => 10)

coordinate Personalizzati a base di ritaglio

Se si consente agli utenti di selezionare manualmente l’area di ritaglio, vi consigliamo di tenere le coordinate x,y in modo persistente il modello in modo da consentire diverse lunghezze di taglio all’immagine originale in futuro. La seguente classe di uploader recupera le coordinate personalizzate dagli attributi dell’oggetto model. Il metodo custom_crop in questo esempio restituisce un Hash di parametri di trasformazione Cloudinary aggiuntivi da applicare.

Se si desidera memorizzare solo la versione ritagliata dell’immagine, è possibile utilizzare una trasformazione in entrata. In questo modo, l’immagine originale non viene memorizzata nel cloud; solo la versione ritagliata. È quindi possibile utilizzare ulteriori trasformazioni per ridimensionare l’immagine ritagliata. L’esempio seguente chiama process :custom_crop nella classe stessa (invece che in una ‘versione’) mentre le coordinate personalizzate vengono mantenute come attributi transitori sul modello (definito con attr invece di memorizzarle in modo persistente).