Discussion :

[yamatoshi]

Bonjour,

Je suis en train de créer un mini projet utilisant FOSUserBundle et HWI Bundle. Je souhaiterais permettre à chaque utilisateur qui s'enregistre via FOSUserBundle d'uploader une image pour son profile et de créer un album perso avec un nombre limité de photos. Avant de me lancer dans le développement d'un Bundle perso, je voudrais profiter de l'expérience des uns et des autres pour savoir s'il n'existerait pas un Bundle qui le fait déjà ?

Car ce qui est dommage dans knpbundles.com c'est que les descriptions des Bundles sont assez sommaires et on ne sait pas tester pour savoir si le bundle répond à ce que l'on cherche.

Merci pour vos réponses

[pmithrandir]

Bonjour,

Si tu trouves, ca m'intéresse.

Pour ma part, je me suis fait la modification à la main sur mon bundle utilisateur.
Ca n'était vraiment pas facile je dois dire.

De ce que je me souviens, le plus galère avait été que l'avatar de mon utilisateur devait étre remis en ligne a chaque edition de celui ci... une vraie galère.
J'avais fini par faire un groupe de validation et une page séparée pour l'upload de l'avatar. (cf https://www.jaiuneidee.net)
Se pose également le problème de la taille des avatars, et de leur redimensionnement. Si tu les affiche en 100px / 100px, ca ne sera peut etre pas le cas dans quelques mois avec un autre design de site.
J'ai pour ma part autorisé les avatars jusqu'à 10MO, mais derrière je les redécoupe avec un bundle nommé gregwar.
Il génère des miniatures et les stocke en cache à la volée. Tu peux en profiter pour afficher l'image dans différentes tailles sur ton site.

Bon courage,
Pierre

[Nico_F]

De ce que je me souviens, le plus galère avait été que l'avatar de mon utilisateur devait étre remis en ligne a chaque edition de celui ci... une vraie galère.

Ça me parait étrange comme comportement, je traite régulièrement des formulaires d'entité ou je dois gérer de l'upload d'image je n'ai jamais eu de galère de ce genre.
Quelle est la problématique ? Ton image était reset à null au moment du save en édition ?

Générer les images à la volée peut-être une idée sympa : j'avais fait quelque chose de similaire dans un ancien projet mais pas en cache : je les stockais physiquement au fur et à mesure qu'elles étaient rendues pour la première fois dans une template.
Le src de l'image était une URL interne de l'appli, dont l'action prenait en paramètre l'image, et la dimension.
Si l'image existait déjà dans cette dimension, elle était retournée immédiatement, sinon elle était crée à partir des dimension demandées en paramètre, sauvegardée et retournée.

Ca permet de ne plus du tout se soucier des différentes tailles d'aperçu sur le site. Si tu rajoutes un nouveau format, tu n'as rien à rajouter du tout au niveau du code.
Tu économises en temps de traitement si l'image existe déjà, mais c'est un peu barbare coté nombre de cycles Request/Response.


@yamatoshi
Créer une galerie d'image n'a rien de très original, qu'est-ce qui t'empêche d'utiliser un bundle déjà tout fait ?

[pmithrandir]

Ça me parait étrange comme comportement, je traite régulièrement des formulaires d'entité ou je dois gérer de l'upload d'image je n'ai jamais eu de galère de ce genre.
Quelle est la problématique ? Ton image était reset à null au moment du save en édition ?

En fait, le problème était que sur la page d'édition, on pouvait, ou pas, avoir envie de changer son image.
Donc, il fallait afficher le champ image_upload, et par défaut, il est plutôt vide quand tu édites l'objet.

Il y avait peut être une solution plus élégante, mais j'ai fait au plus efficace. J'avais été assez déçu du manque de simplicité pour l'upload d'image et le stockage dailleur, ca demandait des notions assez avancée pour les entités(avec des pre-persist, etc...) pour quelque chose qui reste très basique.

Je pense que le système donc je parle fait la même chose que ton bundle en générant à la volée. Moi ça me va en tout cas, ca m'a résolu à moindre frais le problème du redimensionnement d'image et d'upload (les gens se plaignaient quand je limitais la taille à l'upload à moins de 200ko, ils ne savaient pas redimensionner une image) et ca m'évite d'avoir 10 avatar de 200ko par page qui représente vite un gros morceau à télécharger.

[Nico_F]

En édition, il suffit de passer l'entité et de rajouter une balises image à coté du champ input (certes vide) pour montrer la présence d'une image.

Si tu veux faire les choses bien, tu peux même surcharger le widget image de manière à ce qu'il te rende toujours l'image de l'entité juste à coté du champs.
J'avais déjà vu quelque chose de similaire : un widget image qui comprenait :
- l'image (en édition)
- le champs input file
- la checkbox si on veut supprimer sans remplacer par une autre photo.

C'est ce que faisait par défaut symfony1.4 via l'admin generator lorsqu'on faisait le rendu d'un formulaire qui comprenait un champs image.

[yamatoshi]

@yamatoshi
Créer une galerie d'image n'a rien de très original, qu'est-ce qui t'empêche d'utiliser un bundle déjà tout fait ?

Ben justement Nico, c'est la raison de mon topic. Je souhaiterais utiliser un Bundle mais je voudrais, par rapport aux expériences des uns et des autres, savoir lequel serait le plus approprié. Car comme je l'ai dit dans mon sjet d'introduction, dans knpBundle, les descriptions sont assez courtes et on a pas de démo. Donc difficile de faire un bon parmi la dizaine de résultats.

[Nico_F]

Je me le note en rappel ici parce que le sujet a été évoqué, et parce que je crois que je viens de comprendre la vraie problématique que pmithrandir a eu.

Le problème de l'upload d'image (ou de fichier de manière plus globale) dans un formulaire en édition est qu'il est nécessaire d'avoir deux attributs dans l'entité.
- Un attribut imagePath, mappé, qui correspond au path du fichier et qui est une chaine de caractère
- Un attribut imageFile, non mappé, qui correspond au fichier en lui même et qui va être utilisé dans le form type (alors que l'attribut imagePath n'apparait pas du tout)
Les deux ont leur getters et setters classiques.

Ainsi au moment de binder le form à l'objet, comme imagePath n'apparait pas dans le formulaire, il n'est pas écrasé. Par contre, si imageFile possède une valeur, alors on va faire le traitement d'upload et finir par récupérer le filepath et le set à l'attribut imagePath, pour enfin persist/flush notre objet.

De cette manière, l'édition d'un objet n'écrase pas l'ancienne image même si le champs imageFile est laissé vide.

En espérant que ça puisse aider quelqu'un qui passerait par là.
source : http://symfony.com/fr/doc/current/co...e_uploads.html

Pour yamatoshi, en général, mon choix se base (peut-être à tort) beaucoup sur le nombre de fork du bundle.
Si tu vas sur le Github du bundle, qu'il y a une bonne doc, et beaucoup de forks, c'est bon signe. Si la doc est moisie et/ou que personne ne l'a fork ... c'est peut-être pas pour rien ^^ !