csrf token: Required. et admin generator

Version imprimable

Bonjour,

Dans mon application, j'ai créé 2 classes : building et place selon le model suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
   ogi_place:
      _attributes: { phpName: Place }
      # code lieu
      id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
      # nom 
      name: varchar(100)
      # batiment
      building_id : { type: integer, foreignTable: ogi_building, foreignReference: id, onDelete: setnull }
 
   ogi_building:
      _attributes: { phpName: Building }
      # code lieu
      id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
      # nom 
      name: varchar(100)

Pour gérer ça, j'ai utilisé l'admin générator.
Pour remplir la table building, pas de soucis. Par contre pour la table place, il me met une erreur :

Code:

1
2
3
4
Warning: array_key_exists(): The first argument should be either a string or an integer in /usr/local/symfony/symfony1.4.8/lib/util/sfParameterHolder.class.php on line 53 
 
The item has not been saved due to some errors.
    * csrf token: Required.

Une idée du pourquoi ?
Merci.

31/01/2011, 17h29
Michel Rotta

J'ai besoin de savoir quel moteur ORM est utilisé. A priori tu part sur propel, l'ORM le plus utilisé aujourd'hui est Doctrine. Ne serait-il pas mieux de partir sur ce dernier ?

Pourquoi un nom de classe si compliqué ? (préfix ogi_ ?)

Pourquoi un required sur un autoincrémenté ?

Mes souvenirs de propel datent de plusieurs années, a priori ta relation semble bonne. Quid d'une alimentation depuis les fixature ? Quid d'une alimentation depuis un outil externe style phpMyAdmin ?
01/02/2011, 10h30
jejeman

Bonjour et merci de te pencher sur mon problème...
Pour l'ORM, oui c'est propel, mais je n'ai pas le choix...
Pour le nom, ogi c'est le nom de l'application, c'est une convention d'écriture...
Pour le required, c'est vrai que ce n'est pas obligé, mais le modèle a été fait avant moi.. ;), je vais voir si je peux bouger ça...
J'ai essayer une alimentation depuis phpmyadmin, pas de pb !
Merci !
01/02/2011, 11h07
Michel Rotta

Propel, pas de chance .. Reste que c'est un bon ORM qui m'a bien servi, mais j'ai repassé tous sous doctrine pour ne pas avoir à maitriser deux ORM.

Pour OGI, soit, mais est-ce nécessaire dans le nom des entités du modèle ? Pour le nom physique des tables, je peux comprendre (et encore, il y a le nom de la base de données qui doit déjà être OGI quelque chose, mais pour les objets du modèle qui sont dans le code de l'application, cela me semble d'une lourdeur qui a dépassé depuis longtemps le stade de la parano :mouarf: Sauf si toutes vos applications sont développées dans un seul et même environnement... ce dont je doute, fort ;)

Je pense que le problème viens justement du require, regarde si, au moins pour un test en local, tu ne peux pas le supprimer. Pour voir. Une sorte de poker local :mouarf:

Sans le required, c'est pas mieux...
J'ai un autre element dans mon model fait de la meme facon et lui il marche impec !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
   ogi_type_equipment:
      _attributes: { phpName: TypeEquipment }
      # code type
      id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
      # nom 
      name: varchar(100)
      # famille d'equipement
      family_id : { type: integer, foreignTable: ogi_equipment_family, foreignReference: id, onDelete: cascade }
 
   ogi_equipment_family:
      _attributes: { phpName: EquipmentFamily }
      # code famille
      id: { type: integer, required: true, primaryKey: true, autoIncrement: true }
      # nom de la famille (DM, materiel informatique, logistique...)
      name: varchar(100)

Bizarre non ?

01/02/2011, 14h32
Michel Rotta

Essaye la commande : symfony doctrine:clean-model-file

Essaye de nettoyer à la main le dossier lib/model/doctrine et le dossier lib/model/doctrine/base de tous leurs fichiers (attention, il est possible que dans lib/model/doctrine tu aies modifier des fichiers, une sauvegarde serait un plus). Et de régénérer le tous.

Essaye de supprimer dans lib/form le fichier form de cette entité (attention à des modifications éventuelles), supprime aussi celui dans base, pour qu'il recrée le tous à la base. Et recrée.
03/02/2011, 18h16
jejeman

J'ai suivi ta méthode et ça a marché !!!!
Merci ! ;)
16/02/2012, 22h04
trmalek

pour ceux qui se plaint de cet erreur avec Doctrine symfony 1.4
voilà la solution
dans la fonction configure() de la form (dans \lib\form\doctrine\nomtableForm.class.php )
on met
$this->widgetSchema->setNameFormat('nommodule[%s]');
$this->errorSchema = new
sfValidatorErrorSchema($this->validatorSchema);