Discussion :

[jejeman]

Bonjour,

Je me suis rendu compte d'un truc bizarre...
Si j'appelle un form dans un module, il s'affiche différemment que si je l'appelle avec un module générer par l'admin generator...
Dans mon module je fais :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class testformActions extends sfActions
{
 /**
  * Executes index action
  *
  * @param sfRequest $request A request object
  */
  public function executeIndex(sfWebRequest $request)
  {
      $this->form = new sfGuardUserAdminForm();
  }
}

ca donne :
[URL=http://img202.imageshack.us/i/pressepapiers2.jpg/]

Et dans le generator.yml je fais :

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
17
18
19
20
21
22
generator:
  class: sfPropelGenerator
  param:
    model_class:           sfGuardUser
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              sfGuardUser
    plural:                sfGuardUsers
    route_prefix:          sf_guard_user_sfGuardUser
    with_propel_route:     1
    actions_base_class:    sfActions
 
    config:
      actions: ~
      fields:  ~
      list:    ~
      filter:  ~
      form:    
        class: sfGuardUserAdminForm
      edit:    ~
      new:     ~

ca donne :
[URL=http://img842.imageshack.us/i/pressepapiers1.jpg/]

Une idée ?

[bilbonec]

De manière générale, cela ne me choque pas :
- l'admin generator utilise sa propre panoplie de templates, peut-être même de css, du coup l'affichage diffère logiquement (notamment : gestion des fieldset comme "Permissions and groups").

Par contre, tu as des champs en plus dans le formulaire sans admin-generator (tickets, name, firstname, etc.), c'est normal ?

[jejeman]

En fait ce n'était pas l'affichage qui me gênait, car comme tu le dis, l'admin generator utilise ses propre template et autre...
Non ce qui me gêne c'est justement que je n'ai pas les mêmes champs dans les 2 cas...

[bilbonec]

J'avoue ne jamais avoir testé cette méthode :
- générer dans un admin-generator de la classe "x" un formulaire pour l'objet "y".

Mais visiblement cela vient de là :
- tu as fait de l'admin generator sur ton model sfGuardUser ;
- tu lui demandes d'afficher le formulaire sfGuardUserAdminForm dedans.

Apparemment il merge les deux. Reste à savoir si c'est le comportement normal et pourquoi.

[jejeman]

Merci !!!
En fait tu m'as mis sur la piste en me parlant de sfGuardUser et sfGuardUserAdminForm ...
Dans le genrator.yml on appelle spécifiquement le form sfGuardUserAdminForm qui n'existe pas dans mon appli, mais qui existe dans le plugin sfGuardUser
Et quand je regarde dedans, je vois qu'il utilise le form sfGuardUserForm (du plugin aussi car il n'existe pas dans le form de mon appli)
Et quand j'ouvre le sfGuardUserForm du plugin, je vois :

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
17
18
class sfGuardUserForm extends sfGuardUserAdminForm
{
  public function configure()
  {
    parent::configure();
 
    unset(
      $this['last_login'],
      $this['created_at'],
      $this['salt'],
      $this['algorithm'],
      $this['is_active'],
      $this['is_super_admin'],
      $this['sf_guard_user_group_list'],
      $this['sf_guard_user_permission_list']
    );
  }
}

Donc je me dis, je recrée un form dans le lib/ de mon appli, que je défini ainsi :

Code :

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

1
2
3
4
5
6
7
class sfGuardUserForm extends sfGuardUserAdminForm
{
  public function configure()
  {
    parent::configure();
  }
}

Et du coup il ne prend plus celui du plugin mais celui de mon appli où tous les champs sont visibles...
Et donc ca marche !!!

[bilbonec]

Oh attends !!
Tu veux dire que le

Code :

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

1
2
3
4
5
6
7
class sfGuardUserForm extends sfGuardUserAdminForm
{
  public function configure()
  {
    parent::configure();
  }
}

tu l'as définis dans ton projet à toi ??

Si c'est le cas, c'est assez dangereux d'un point de vue capacité à bugger : il faut absolument que tu donnes à tes classes des noms différents de ceux qu'il y a dans Symfony ou tes plugins, sinon tu vas vite te faire des cheveux blancs à ne jamais être certain de savoir quelle classe (celle que tu as écrite ? Celle du plugin ?) va être réellement appelée.

Si ce n'est pas le cas, il y a quelque chose que je n'ai pas compris, car :
- c'est sfGuardUserAdmin qui étend de sfGuardUser, et non l'inverse.

[jejeman]

Oui je l'ai redéfini dans mon projet...
Mais bon, par défaut, il prend les données dans le projet et seulement ensuite dans le plugin, non ?
Sinon je vois pas comment redéfinir les choses dans mon projet, vu que je cherche à mixer des données du plugin et du projet....

[bilbonec]

Mais bon, par défaut, il prend les données dans le projet et seulement ensuite dans le plugin, non ?

Effectivement. Mais c'est une pratique de manière générale bien risquée et qu'il est facile d'éviter.

Je ne sais plus si tu l'avais posté dans un autre topic, mais pour définir comment organiser tout ça, tu pourrais décrire explicitement ce que tu veux avoir ?

[jejeman]

OK, j'explique...
Dans mon appli, je veux gérer les utilisateurs plus finement avec le plugin sfGuardUser.
Cependant, au niveau des informations supplémentaires que propose le plugin sur les users, c'est pas ça, d'ailleurs dans la documentation il préconise de modifier le model pour ajouter une classe "profil".
Donc j'ai créé une classe sfGuardUserProfile avec une clé étrangère vers la classe sfGuardUser.
La gestion des users se fait grâce à un module auto générer dans le plugin. Ce module prend bien en compte la gestion des permissions et des groupes sauf qu'il ne prend pas en compte le profile que j'ai créé.
Donc j'ai décider de générer avec l'admin generator un module sfGuardUser dans mon appli pour gérer mes users, car dans ce cas il va prendre en compte mon profile. En effet le profile est bien géré, mais du coup il ne gère plus les notions de permissions et de groupes alors que le module du plugin le faisait.
Comment faire ?
Merci.

[bilbonec]

Vu que ce sont des profils que tu veux gérer, pourquoi ne pas lancer l'admin-generator sur sfGuardUserProfile ?

Dans le formulaire sfGuardUserProfileForm, je crois qu'il faudrait dans ce cas remplacer la déclaration de ta relation à sfGuardUser par un embedForm :

Code :

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

$this->embedForm('User', new sfGuardUserForm());

Cela devrait ressembler à quelque chose comme ça, malheureusement je n'ai plus le code que j'avais fait pour le réaliser

[jejeman]

Bon j'ai essayé de suivre tes conseils :

Code :

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

./symfony propel:generate-admin --module="sfGuardUserProfile" backend sfGuardUserProfile

ensuite si je vais sur mon module, il me dit :
Fatal error: Class 'sfGuardUserProfileFormFilter' not found in /usr/local/symfony/symfony1.4/lib/generator/sfModelGeneratorConfiguration.class.php on line 496
En y réfléchissant, on ne gere pas vraiment un profile, mais plutot un user qui a un profil....

[bilbonec]

Dans ce cas l'inverse effectivement :
- générer l'admin-generator sur sfGuardUser ;
- et dans lib > form > doctrine > sfDoctrineGuardPlugin > sfGuardUserForm :

Code :

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

$this->embedForm('fieldName', new sfGuardProfileForm());

quelque chose comme ça.

(désolé pour le post précédent, je crois que j'avais en tête mon propre modèle et j'ai mélangé le tout )

[jejeman]

Mais dans ce cas, ca revient a la même chose que j'ai déjà fait, à savoir créer un 2eme sfGuardUserForm (en plus de celui du plugin) dans mon appli...

[bilbonec]

Justement, celui que tu as créé toi est-il effectivement celui qui était pris en compte, ou bien celui dans lib > form > doctrine > sfDoctrineGuardPlugin > sfGuardUserForm ?

Sinon désolé, mais je sèche là ...

[jejeman]

Oui c'est bien le mien qui est pris en compte...