[Bonjourgem] Paperclip (fr)

Quelques idées en vrac pour les prochains bonjourgem :
• carrierwave
• meta-tags
• settingslogic
• find_by_param
• activevalidators
• html5-boilerplate
• rails_autolink
• jbuilder

J'espère que ça pourra t'aider :)

Certaines ne sont pas dans ma liste actuel donc oui ça m'aide :p

Un tour sur https://www.ruby-toolbox.com/ devrait de donner un max d'idées aussi :)

Bah ça et les twitters de certains grand monsieur me servent de ressources déjà !

La philosophie de paperclip semble tellement dépassée après qu'on ait utilisé carrierwave ou dragonfly.

Jamais utilisé ces gems, en regardant les docs sa ressemble pas mal à paperclip après faut voir à l'usage :)

David, non. Les philosophies de Carrierwave et Dragonfly sont différentes de Paperclip.

J'ai pas envie d'écrire un roman maintenant pour expliquer les pros-cons.

Disons qu'après usage je préfère utiliser Carrierwave si mes fichiers sont hébergés sur Amazon S3 et si c'est du dédié j'utilise Dragonfly.

Faudra que j'essaye Carrierwave et Dragonfly alors :)

À la louche, celles que j'utilise le plus :
* zurb-foundation
* kaminari
* resque (et resque-mailer & resque-scheduler)
* mongoid
* exception_notification

@Nicolas Blanco : le roman m'intéresse entre Paperclip/Carrierwave !
Si tu as 2/3 points à partager, je suis tout ouï.

@Nicolas Blanco : Le roman m'intéresse aussi, surtout que je ne connais pas dragonfly et que je pensais qu'il n'y avait que paperClip et Carrierwave dans la compétition.

RedCloth me semble intéressant !
coderay aussi pourquoi pas

@Nicolas Blanco : Ouais une petite comparaison des trois !
Généralement pour choisir une gem je me base sur son classement dans https://www.ruby-toolbox.com/categories/rails_file_uploads mais je suis ouvert hein :D

Dans Paperclip et ses prédécesseurs (attachment_fu et file_column) on insère toute la logique d'upload dans le modèle sous la forme d'un hash d'options.

On insère aussi des éléments de vue (taille des thumbs) directement dans le modèle.

Dans Carrierwave, on externalise la logique d'upload dans des classes à part. C'est déjà beaucoup plus flexible et DRY. Si plusieurs modèles ont la même logique de traitement des uploads, on réutilise la même classe. Pas besoin de bidouiller, créer des contantes ou des modules... On peut facilement étendre les classes Uploader avec des méthodes de processing custom, c'est donc beaucoup plus flexible qu'un simple hash d'options.

Dragonfly est totalement différent et est composé en partie d'une application Rack. La logique est que le traitement des uploads est effectué directement au moment où la vue est appelée puis mis en cache. L'information sur la taille de la miniature se trouve directement dans la vue. Plus besoin de reprocesser les miniatures, plus besoin de modifier du code Ruby si dans une vue on a besoin d'une taille de miniature différente ou d'un autre processing.

Cette solution semble a première vue parfaite, malheureusement elle oblige forcément à générer des URLs qui vont taper sur l'appli Rack de Dragonfly, qui va se charger soit de processer, servir puis cacher, soit directement servir/rediriger.

Donc cette philosophie n'est pas parfaite si on compte envoyer les fichiers sur Amazon S3 ou un hébergeur de fichiers cloud où l'avantage est de pouvoir les lier directement et éviter des appels sur sa propre architecture.

merci beaucoup pour cette explication

Je remets le badge du plus long commentaire de RubyLive à Nicolas :)