Le 7 septembre 2008 17:06, Yann KLIS [email protected] a écrit :
Donc pour le moment, Ã part si tu argumentes un petit peu, ton
commentaire au sujet de attachment_fu ressemble à du FUD.
Je ne vois pas vraiment en quoi le fait d’attacher différents types de
fichiers à un modèle doit poser problème, peut-être que tu as un exemple
concret en tête ?
Au contraire d’attachment_fu qui impose d’avoir un modèle pour chaque
type
de document, avec paperclip tu peux directement attacher un document
dans la
table de l’élément qui l’héberge, mais tu n’est pas obligé de le faire.
Si
par exemple tu veux une liaison de type has_many, tu peux très bien
faire un
modèle Document pour héberger le doc, et qui porte l’association ; au
contraire, la BD reste beaucoup plus propre parce que tu n’es pas forcé
de
faire des modèles en plus pour attacher un document dans une liaison de
type
has_one.
Ensuite, l’héritage au sens sti c’était totalement déconseillé avec
attachment_fu, j’ai essayé, je te conseille d’éviter. Pareil avec
paperclip,
sauf qu’avec paperclip tu n’en a pas autant besoin, puisque tu n’as pas
besoin de créer des modèles spécifiques pour héberger la plupart des
fichiers.
Pour faire qu’un modèle Document soit attachable à plusieurs autres
modèles,
tu peux faire :
class Document
…
has_attached_file …
…
belongs_to :attachable, :polymorphic => true
end
class Page
…
has_many :assets, :as => :attachables
…
end
class Chapters
…
has_one :asset, :as => :attachable
…
end
Mais en supposant que le modèle Chapters veuille seulement une image
d’illustration, ce serait plus pertinent de faire :
class Chapters
…
has_attached_file …
…
end
Ce qui t’évite de faire des héritages sti pour simplement modifier la
façon
dont le fichier associé est traité.
Pour le support de plusieurs backends, je ne dis pas. C’est juste que ça
ne
me sert à rien, je préfère un backend qui marche sur l’essentiel des
plateformes et qui n’est pas gourmand. Il se trouve qu’utiliser
imagemagick
directement en ligne de commande remplit ces deux fonctions, qu’en plus
ça
m’évite d’avoir à compiler sur le serveur de l’hébergeur une version
spécifique d’ImageMagick pour que ça marche avec le module ruby (je me
suis
tapé deux fois cette opération à cause d’attachment_fu, ça ira je n’ai
pas
envie d’en faire une 3°).
Enfin, il faut bien reconnaître que le code de attachment_fu est très
ardu Ã
lire et à comprendre, ce qui m’a fait perdre un temps fou du temps où je
cherchais à lui donner une toute petite fonctionnalité en plus (pouvoir
générer un onglet en recadrant une zone spécifique ; ça ne semble pas
compliqué dit comme ça, mais au bout du 4° problème sérieux et imprévu
j’ai
commencé à trouver que le principe de moindre surprise était
sérieusement
mal en point).
Pour faire la même chose avec paperclip, j’ai mis 1/2 journée de l’idée
à la
réalisation complète et sans bug.
Bon, voilà , je crois que j’ai assez argumenté.
Ah, si une dernière chose, je ne vois pas pourquoi tu m’accuse de faire
du
FUD. Si je ne me trompe pas, FUD ça veut dire “Fear, Uncertainty and
Doubt”,
et si je ne me trompe toujours pas :
- je n’ai pas essayé de faire peur à qui que ce soit
- je n’ai pas non plus essayé d’embrouiller qui que ce soit
- je n’ai pas non plus essayé de faire douter qui que ce soit
J’ajoute que je n’ai pas d’actions dans l’entreprise richissime qui vend
Ã
prix d’or le brevet de paperclip, et pas non plus d’intérêt à détruire
le
formidable fleuron étendard du logiciel libre qu’est attachment_fu, si
ce
n’est que je le trouve très en-dessous du premier de tous les points de
vue
qui m’intéressent (facilité de prise en main, facilité d’utilisation,
facilité d’amélioration, facilité d’installation et de mise en
production).
Merci donc de m’épargner les comparaisons gratuites avec les tenants de
logiciels propriétaires et leurs pratiques véreuses.
–
Michel B.