Discussion :

[Bleys]

Bonsoir à tous,

J'étais habitué à développer des applications web sous symfony1.X. Je connais plutôt bien ce framework et ... les choses évoluant, je me suis naturellement dit qu'il fallait que je m'intéresse à Symfony2 (décidément la com' de Fabien Potencier marche plutôt pas mal ). Bref ...

Je pense que c'est une erreur mais ... compte tenu de l'investissement déjà effectué, je pense qu'il est un peu tard pour faire machine arrière : pour gérer mes utilisateurs, j'ai voulu immédiatement utiliser le Bundle FOSUserBundle. Je m'attendais à ce qu'il s'agisse d'un Bundle qui gère "tout pour nous". Seulement plus ça va ... et plus je me dis qu'il n'est pas réellement là pour ça.
Le manque cruel de documentation digne de ce nom pour ce Bundle ne facilite pas les choses.

Ma question est donc somme toute simple : comment utilise-t-on ce Bundle ? Je m'explique :
la création de la classe propre à mon appli surchargeant le User du Bundle => done
mais le reste ? Je veux dire par exemple le formulaire d'inscription d'un utilisateur ? Le système fourni par le Bundle est naturellement trop minimaliste ... quelle est la bonne méthode pour le modifier ?
Dois-je tout refaire par moi-même ? Dois-je surcharger le formulaire (et son handler) et modifier le fichier de config pour lui dire quels sont les nouveaux Formulaire et Handler ? Auquel cas ... comment faire ?
Et supposons que, dans ma classe user, il y ait un champ lié à une autre table ... comment mettre une valeur par défaut à la création d'un user ?

Egalement, le FOSUserBundle propose des controller par défaut (la visualisation d'un profil utilisateur). Là-encore les données sont trop minimaliste. Comment personnaliser ceci ? Le seul moyen que je vois pour le moment est de créer mon propre controller (dans mon Bundle) et repartir à zéro ... ce qui finalement revient à dire que les Controller de FOSUserBundle ne sont ni plus ni moins que des démos et exemples d'utilisation.

Je commence à m'habituer aux différents concepts de sf2 (et Doctrine2 aussi en fait), mais j'avoue que là j'ai déjà perdu pas mal de temps sur ce Bundle ... je commence à en comprendre les tenants et aboutissants, mais une aide est la bien venue.

Si vous pouviez apporter lumière à mes questions, ce serait top !

J'en profite pour vous demandez : si vous connaissez un projet open-source utilisant le FOSUserBundle ... je suis également preneur.


Merci par avance,

[dourouc05]

ce qui finalement revient à dire que les Controller de FOSUserBundle ne sont ni plus ni moins que des démos et exemples d'utilisation.

Il est déconseillé de les utiliser en production, par exemple, je pense que tu es donc dans le bon en disant ça .

Sans trop répondre à tes autres questions, je peux te conseiller d'aller jeter un coup d'oeil à http://www.developpez.net/forums/d10...-applications/, ça pourrait débloquer un peu.

Pour des applications qui l'utilisent, j'en ai vu sur http://symfony2bundles.org/project (mais j'ai fermé mes onglets de recherche depuis lors ).

[Bleys]

Avant tout merci pour ta contribution.

Sans trop répondre à tes autres questions, je peux te conseiller d'aller jeter un coup d'oeil à http://www.developpez.net/forums/d10...-applications/, ça pourrait débloquer un peu.

J'ai déjà fait un tour par ici ... mis à part la création d'un Bundle spécifique pour gérer ses utilisateur (et donc la présentation de comment initialiser le FOSUserBundle) l'exemple fourni n'est pas suffisant. Exemple tout bête, ce sont les Controller de FOSUserBundle qui sont utilisés dans l'application ... ce que l'on a à juste titre normalement dit qu'il ne fallait pas faire ...

Pour symfony2Bundle ... je vais donc continuer mes recherches.

Merci encore,


Evidemment mon topic reste ouvert car toutes mes questions sont toujours d'actualité !

[Bleys]

Je viens de trouver un projet AssoManager ... qui utilise FOSUserBundle ... mais qui contient son propre UserBundle ... ça devrait pouvoir répondre à mes questions + mon autre sujet ... je vais voir si c'est vraiment le cas ...

AssoManager : https://github.com/winzou/AssoManager
github : https://github.com/winzou/AssoManager.git


Cela dit je suis toujours preneur de toute remarque !

... en fait non ... Le Controller est vide ...

Je continue mes recherches ...

[winzou]

Salut,

Pourquoi tu trouves que les controleurs de FOS sont trop minimalistes ?

Ils font globalement ce qu'on leur demande de faire. Ce que tu veux personnaliser c'est surtout les templates, les formulaires et l'entite evidemment.

Tout ca tu peux le faire en changeant les valeurs de config, cf tout en bas de https://github.com/FriendsOfSymfony/.../doc/index.rst

Tiens nous au courant (je parle je parle mais je l'ai jamais fait )

[Bleys]

Salut,

Je dis qu'ils sont trop minimaliste car la classe que l'on crée pour représenter le User (héritant de FOSUserBundle) contient des données dont le Bundle n'est pas au courant. Donc à la création, il y a nécessairement un soucis (imaginons une référence à une autre table ... nécessaire ... et qui par défaut - à la création du user - doit prendre une certaine valeur : les controllers actuels sont trop minimaliste).

Mais j'en reviens alors un peu à ce que je disais : il vaut peut-être mieux surcharger les formulaire (XXXXFormType) et les Handlers associés (XXXXFormHandler) qui permettent (si je ne m'abuse) de traiter un formulaire.
Peut-être faut-il aussi pour le cas que j'expose, surcharger le UserManager ? (sur le UserManager::createUser je défini ma logique spécifique supplémentaire au moins ...)


Soit dit en passant : où est défini dans le FOSUserBundle la classe par défaut pour le paramètre fos_user.user_manager ? Je ne trouve pas ce paramètre ?

Merci,

[Bleys]

Salut,

Soit dit en passant : où est défini dans le FOSUserBundle la classe par défaut pour le paramètre fos_user.user_manager ? Je ne trouve pas ce paramètre ?

Ok il est dans la config du FOSUserBundle orm.xml (pour ceux qui ont configuré en orm) chargé depuis FOSUserExtension

[winzou]

Oui voila il faut modifier d'abord les FormType et FormHandler. Et si tes modifs ne peuvent pas tenir la dedans, ensuite attaquer les controleurs si besoin.

Pour la classe attention tu n'as pas a la changer, pourquoi tu veux faire ca ?

[Bleys]

,

Oui voila il faut modifier d'abord les FormType et FormHandler. Et si tes modifs ne peuvent pas tenir la dedans, ensuite attaquer les controleurs si besoin.

Pour la classe attention tu n'as pas a la changer, pourquoi tu veux faire ca ?

Non non je ne veux pas spécialement la changer (je suppose que tu parles du UserManager). Je voulais juste savoir où elle était définit (pour pouvoir jeter un oeil dedans et comprendre son fonctionnement).
Tout du moins dans un premier temps ... en effet si je souhaite que la ligne de commande fonctionne toujours (fos:user:create par exemple) - je ne me suis pas encore penché sur le problème - étant donné que le form et le handler n'intervienne pas à ce niveau (enfin je ne pense pas) c'est le UserManager qu'il faudra que je rende plus spécifique ... donc surcharge donc précision du fos_user.user_manager ...

Mais ce n'est ici que spéculation.

[Bleys]

Bon ... je pensais faire une version amélioré du formulaire de création d'utilisateur (puisque dans mon cas seul un administrateur peut créer des users) et je me suis dit : autant utiliser le RegistrationFormType de FOSUserBundle.
Pour faire simple, admettons que je souhaite ajouter une simple case à cocher pour savoir si l'utilisateur créé est un admin ou pas.
Je mets ceci en place :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
<?php
namespace ME\MonBundle\Form\Type;
 
use FOS\UserBundle\Form\Type\RegistrationFormType;
 
class UserFormType extends RegistrationFormType
{
  public function buildForm(FormBuilder $builder, array $options)
  {
    parent::buildForm($builder, $options);
    $builder
      ->add('admin', 'checkbox')
    ;
  }
}

Mais alors ... comment gérer cette donnée par la suite ? Je veux que si cette case est cochée, définir le role ROLE_ADMIN au User ... Comment faire ?

Je pensais surcharger le RegisterFormHandler ... mais je ne sais comment faire (je veux dire ... quoi surcharger ? surcharger la méthode process reviendrait presque à refaire un Handler complet qui correspond à mes attentes) . En fait actuellement je vois une potentielle solution en recréant le Controller moi-même ... mais je trouve ça un peu lourd ... et puis j'ai une problématique aussi au niveau de l'initialisation de ce champ pour un edit (si hasRole('ROLE_ADMIN') => cocher la case) ...

Finalement, on en revient toujours un peu à ma question initiale : quel est le réel but de ce Bundle, que m'apporte-t-il de plus ? Il gère certes la connexion et un enregistrement très basique ... mais pas un crud exhaustif ... (normal en même temps). Mais alors comment s'en servir ? Dois-je surcharger leur formulaires ou repartir à zéro et simplement utiliser le fos_user.user_manager pour effectuer mes enregistrements ?

Merci à quiconque voudra m'aiguiller.


[edit] et si dans ma classe User je rajoute deux méthodes isAdmin() et setAdmin() ... ça semble pouvoir le faire ... mais quelle est la bonne façon de procéder alors ?

[winzou]

Je comprends pas pourquoi tu es reticent a surcharger le formHandler ? Tu peux tout y faire dedans quasiment.

Bon ton cas est un peu tordu car tu fais un formulaire qui modifie autre chose qu'un attribut de ton entite. Clairement un isAdmin sur ton User serait plus simple, mais facultatif.

[Bleys]

Je comprends pas pourquoi tu es reticent a surcharger le formHandler ? Tu peux tout y faire dedans quasiment.

En fait ... je ne suis pas spécialement réticent à le surcharger, mais finalement c'est que rien n'est surchargeable ... redéfinir la méthode process() veut dire "reprendre la méthode process() complète" ... donc ... oui c'est envisageable ... mais à priori pas nécessairement la meilleure façon de faire.

Bon ton cas est un peu tordu car tu fais un formulaire qui modifie autre chose qu'un attribut de ton entite. Clairement un isAdmin sur ton User serait plus simple, mais facultatif.

Là je ne suis pas vraiment d'accord. Je ne cherche pas à modifier autre chose qu'un attribut de mon entité ... je cherche à faciliter la saisie d'une donnée pour un utilisateur. La propriété "est administrateur" se traduit par l'ajout d'un rôle à l'utilisateur ... c'est donc bien un attribut de mon entité (même si isAdmin n'existe pas directement dans mon entité).

En fait, je suis en train d'en arriver à la conclusion que FOSUserBundle sert "juste" (entre guillemets on est bien d'accord) à gérer tout ce qui a attrait à l'authentification et l'autorisation ... ce n'est pas pour gérer ton listing d'utilisateurs, pour créer tes utilisateurs etc. Il ne peut se suffir à lui-même et un Bundle propre à mon application est donc nécessaire (listing, édition, ...).

Tout du moins, c'est la conclusion à laquelle je suis arrivé.

[ertyu]

Salut,

Je suis en train de découvrir ce bundle et je me pose un peu les mêmes questions que toi. C'est pas évident, il n'y a aucune doc ...

Pour l'instant je reste dans des cas simples (toutes les champs du formulaire sont dans l'entité User) et je pense, à priori que ça devrait le faire s'il s'agit juste d'ajouter des propriétés simples. Pourquoi tu ne mets pas ton "isAdmin" dans l'entité ?

Tu as réussi à surcharger le formulaire de ton côté ?

Dans mon config.yml j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
fos_user:
[...]
    registration:
      form:
        type:  user_registration
        handler:  fos_user.registration.form.handler.default
        name:  fos_user_registration_form
        validation_groups:  [Registration]

Et j'ai défini le service :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<service id="user.registration.form.type" parent="fos_user.registration.form.type" class="Proj\UserBundle\Form\Type\UserFormType">
       <tag name="form.type" alias="user_registration" />
</service>

Mais je reçois comme erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Fatal error: Declaration of Proj\UserBundle\Form\Type\UserFormType::buildForm() must be compatible with that of Symfony\Component\Form\FormTypeInterface::buildForm() in C:\Wamp\www\Symfony\src\Proj\UserBundle\Form\Type\UserFormType.php on line 7

La fonction buildForm est basique, j'ai rien changé. L'erreur est peut-être évidente je débute sur Symfony.

Merci.

[winzou]

Montre ton UserFormType ?

[ertyu]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
namespace Proj\UserBundle\Form\Type;
 
use FOS\UserBundle\Form\Type\RegistrationFormType;
 
class UserFormType extends RegistrationFormType
{
 
    public function buildForm(FormBuilder $builder, array $options)
    {
        parent::buildForm($builder, $options);  
    }   
}

Merci.

[winzou]

Le piège vicieux :p

Rajoute use Symfony\Component\Form\FormBuilder; en haut Pour PHP le FormBuilder que tu utilises dans la définition de ta fonction n'est pas le même que celui que Symfony2 utilise, d'ou l'erreur.

[ertyu]

En effet. Merci beaucoup.

[Bleys]

Désolé, j'ai pas trop eu accès au forum la semaine passée. Mais winzou veillé au grain et t'a apporté toutes les bonnes réponses manifestement

A ta question :

[...]
Pourquoi tu ne mets pas ton "isAdmin" dans l'entité ?
[...]

ma logique a été de me dire "qu'est-ce que, dans mon cas, signifie être administrateur ?" La première réponse qui m'est venue c'est que "être administrateur, c'est avoir le role ROLE_ADMIN". Donc finalement, mon entité User, n'a pas besoin d'un attribut supplémentaire "isAdmin" ... cette donnée étant déjà disponible dans la colonne "roles" du FOSUserBundle\model\User. ainsi mes fonctions setIsAdmin() et isAdmin() traitent correctement ce cas par elles-mêmes.
Le tout était de savoir comment gérer ça avec le FOSUserBundle.

[benderpremier]

Dites moi si je suis totalement hors sujet, mais je me pose des questions concernant la manière d'étendre un Bundle. Par exemple dans notre cas si on veut adapter FOSUserBundle on met dans le fichier NouveauBundle.php :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	public function getParent()
		{
			return 'FOSUserBundle';
		}

Et ensuite à chaque fois qu'on à besoin d'adapter un méthode ou d'en créer un nouvelle, on crée un classe qui étend la classe correspondante dans FOSUserBundle. Et on la crée dans le même répertoire. par exemple si on veut étendre le RegistrationController on crée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php
 
 
 
namespace MyApp\UtilisateurBundle\Controller;
 
use FOS\UserBundle\Controller\RegistrationController as FOSRegistrationController;
use Symfony\Component\DependencyInjection\ContainerAware;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Exception\AccessDeniedException;
use FOS\UserBundle\Model\UserInterface;
 
 
class RegistrationController extends FOSRegistrationController

?

merci d'avance

EDIT FOSUserBundle a sa documentation qui s'étoffe...

[winzou]

C'est ca, sauf que tu peux pas tout changer juste en mettant un fichier du même nom dans ton bundle. Ca marche pas pour les services, juste pour les contrôleurs, templates, et fichiers de config surement.

Et effectivement, la doc de FOSUB est enfin digne de ce nom !