Discussion :

[sebastien.bd]

Je me familiarise depuis deux jours avec les plugins sfDoctrineGuardPlugin et sfForkedDoctrineApplyPlugin. Ils sont maintenant correctement installés et configurés.
Je veux ajouter les champs à sfGuardUser (ex: code postal et date de naissance). J'ai donc essayé ce qui est indiqué le READ ME de sfForkedDoctrineApplyPlugin. J'ai ajouté dans mon schema.yml :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Profil:
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: 1
  columns:
    cp:
      type: string(7)
    birthday:
      type: date

Quand je mets dans data/fixtures/profil.yml :

Code :

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

1
2
3
4
5
6
7
8
Profil:
  webadmin:
    email_address:  tata@toto.fr
    username:       webadmin
    password:       webadmin
    is_super_admin: true
    cp: 94300
    birthday: 1977-09-08

Tout fonctionne. Il crée un utilisateur de type 1 avec un code postal à 94300. (Bon, en fait il laisse le champ birthday à 0000-00-00, mais je creuserai ça plus tard).

Je veux maintenant que lorsque qu'un utilisateur créé un compte, le formulaire d'inscription intègre les champs cp et birthday.

Je pensais que la bonne option était de surcharger le formulaire sfApplyApplyForm du plugin. J'ai donc créé dans lib/forms, le fichier applyForm.class.php :

Code :

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

1
2
3
4
5
6
7
8
 
class applyForm extends sfApplyApplyForm {
 
	public function configure(){
		parent::configure();
		...
	}
}

Mais visiblement ce formulaire n'est jamais chargé.
Je tourne en rond et je ne trouve pas de réponse sur les forums :
1) Suis-je sur la bonne voie ?
2) Si oui, comment surcharger ce formulaire ?
Merci d'avance pour votre aide.

[Michel Rotta]

Il faut envisager de définir la table directement dans ton shema.yml en fusionnant les informations de shema des deux plugin.

Si non, l'ajout des champs ne se fait que pour les objets hérité et ne sera jamais vu par le formApply.

[sebastien.bd]

Merci pour ta réponse, mais je suis plutôt newbie en symfony et ce que tu me dis ne me parle pas trop.

Ce que j'ai compris c'est que le dois définir dans mon schema.yml une table sfGuardUser qui va surcharger celle définie par le plugin. Si c'est ça j'ai ajouter ceci à mon schéma :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
sfGuardUser:
  actAs: [Timestampable]
  columns:
    first_name: string(255)
    last_name: string(255)
    email_address:
      type: string(255)
      notnull: true
      unique: true
    username:
      type: string(128)
      notnull: true
      unique: true
    algorithm:
      type: string(128)
      default: sha1
      notnull: true
    salt: string(128)
    password: string(128)
    is_active:
      type: boolean
      default: 1
    is_super_admin:
      type: boolean
      default: false
    last_login:
      type: timestamp
    cp:
      type: string(7)
  indexes:
    is_active_idx:
      fields: [is_active]
  relations:
    Groups:
      class: sfGuardGroup
      local: user_id
      foreign: group_id
      refClass: sfGuardUserGroup
      foreignAlias: Users
    Permissions:
      class: sfGuardPermission
      local: user_id
      foreign: permission_id
      refClass: sfGuardUserPermission
      foreignAlias: Users

Mais comment faire pour que le formulaire d'inscription incorpore automatiquement les nouveaux champs ?

J'ai aussi vu que sfForkedDoctrineApplyPlugin définisait une table sfGuardUserProfile. Est-ce qu'il est plus judicieux d'étendre celle-ci ?

Je me noie surement dans un verre d'eau mais je me sens un peu perdu. J'imagine quelques solutions mais ça me parait de la bidouille et j'aimerais partir sur de bonnes bases.

[Michel Rotta]

J'ai très peu de temps hélas ces jours ci.

Il faut faire la fusion des deux tables, celle de sfGuard et celle définie dans sfFDAP. Et y rajouter tes champs.

Le form de base est généré par symfony en fonction des champs. Ensuite il est affiché. Normalement (a vérifier) sfFDAP ne fait qu'un simple render sur le form de base. Donc les champs rajouté y apparaîtrons. Si non il reste possible de redéfinir localement le template, on verra à ce moment là.

[sebastien.bd]

Eureka !
Merci de m'avoir mis sur la piste. J'ai essayé tellement de choses (un fil des post que j'ai pu lire !) que je n'arrivais plus à m'y retrouver. Tout cela me semble maintenant plutôt basique, mais je fais un petit topo quand même, ça peut servir :

BUT : Je veux que les utilisateurs de mon appli s'identifient et je veux associer au formulaire d'enregistrement des parametres propres à mon appli : code postal, ville, date de naissance, localisation....

1 - Installation des plugins : sfDoctrineGuardPlugin (qui gère l'identification et les permissions) et sfForkedDoctrineApplyPlugin (alias sfFDAP, qui ajoute quelques fonctions bien pratiques dont la récupération de mot de passe oublié). Pour l'installation, les README des deux plugins sont très bien faits.

2 - Quand sfFDAP affiche le formulaire d'enregistrement, il s'appuie sur le modèle sfGuardUserProfile dont il donne une définition dans son schema.yml :

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
23
24
25
26
27
28
29
30
31
32
 
sfGuardUserProfile:
  actAs:
    Timestampable: ~
  columns:
    user_id:
      type: integer
      notnull: true
      unique: true
    email_new:
      type: string(255)
      unique: true
    firstname:
      type: string(255)
    lastname:
      type: string(255)
    validate_at:
      type: timestamp
    validate:
      type: string(33)
  relations:
    User:
      class: sfGuardUser
      foreign: id
      local: user_id
      type: one
      onDelete: cascade
      foreignType: one
      foreignAlias: Profile
  indexes:
    validate:
      fields: [validate]

Pour compléter ou modifier ce modèle, deux solutions :
- utiliser l'héritage de Doctrine dans votre propre schema en étendant sfGuardUserProfile avec les champs dont vous avez besoin :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Profil:
  inheritance:
    type: column_aggregation
    extends: sfGuardUserProfile
  columns:
    cp:
      type: string(7)
    ville:
      type: string(40)
    localisation:
      type: string(60)
    naissance:
      type: date

- ou surcharger complètement la définition du plugin, en déclarant dans votre schéma le modèle sfGuardUserProfile.

et on construit la base de donnée : php symfony doctrine:build --all --and-load

3 - Si tout s'est bien passé, /user/new (la route par défaut de sfFDAP pour afficher le formulaire d'enregistrement) vous affiche un joli formulaire incluant les champs que vous avez défini dans votre modèle !

On pourrait s'arrêter là mais c'est dommage car le meilleur reste à venir. En effet, nos champs s'affichent bien dans le formulaire, mais leur libellé est le même que dans la base de donnée : Cp et Naissance ne font pas le meilleur effet. Il nous faut donc modifier le formulaire.

4 - sfFDAP fournit le formulaire sfApplyApplyForm, qui se charge d'afficher le formulaire d'enregistrement. Et ce formulaire hérite de sfGuardUserProfileForm. Ce dernier a gentiment été placé par Doctrine dans votre dossier /lib/form/doctrine/sfForkedDoctrineApplyPlugin... ce qui veut dire que vous pouvez modifier directement cette classe puisqu'elle ne sera pas écrasé lors du prochain doctrine:build :

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
 
class sfGuardUserProfileForm extends PluginsfGuardUserProfileForm
{
  public function configure()
  {
  	parent::configure();
// Vous pouvvez supprimer les champs que vous ne voulez pas afficher
	unset($this['localisation']);
 
// Modifier les labels de vos champs perso
	$this->widgetSchema->setLabels(array(
		'cp' => 'Code postal',
		'naissance' => 'Date de naissance'
	));
  }
}

5 - Petit bonus : vous pouvez dans la fonction configure() écraser les widgets et les validateurs par défaut et les redéclarants.
ex : le champ date ne me convient pas pour une date d'anniversaire. Je veux augmenter le nombre d'années proposé par le widget et je veux utiliser le widget JQuery. Après avoir installé sfFormExtraPlugin (pour utiliser le widget JQuery), j'ajoute à ma fonction configure() :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
$years = range(strftime("%Y"), strftime("%Y", strtotime("-100 years")));
 
$this->setWidget('naissance', new sfWidgetFormJQueryDate(array(
	'image' => '/images/calendar.png',
	'culture' => 'fr',
	'date_widget' => new sfWidgetFormI18nDate(array(
		'culture' => 'fr',
		'years' => array_combine($years, $years)))
)));

Et voilà le travail. Bonne route à tous ceux que ça aidera