Discussion :

[rastaferraille]

Bonjour,

J'ai quelque champs pour un formulaire qui ne se sauvegardent pas, je ne comprends pas pourquoi...

Voici mon Yaml

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    horaire_matin_debut:
      type: time
      notnull: true
    horaire_matin_fin:
      type: time
      notnull: true
    horaire_apres_midi_debut:
      type: time
      notnull: true
    horaire_apres_midi_fin:
      type: time
      notnull: true

Impossible de mette à jour depuis mon appli le champ horaire_matin_debut alors que tout fonctionne pour les autres...

Je n'arrive pas à comprendre d'où ça peut venir..

Il n'y a rien de particulier dans mon form :

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
47
48
49
$this->setDefault('horaire_matin_debut', "08:00");
		$this->setDefault('horaire_matin_fin', "12:00");
		$this->setDefault('horaire_apres_midi_debut', "14:00");
		$this->setDefault('horaire_apres_midi_fin', "18:00");
 
		....
 
 
		$this->widgetSchema->setLabels(array(
			'matricule_rh' => 'Matricule de la victime',
			'date_creation' => 'Date de création',
			'date_premiers_soins' => 'Date',
			'heure_premiers_soins' => 'Heure',
			'lieu_premiers_soins' => 'Lieu',
			'premiere_personne_avisee_nom'	=> 'Nom',
			'premiere_personne_avisee_prenom'	=> 'Prénom',
			'date_accident' => 'Date',
			'heure_accident' => 'Heure',
			'lieu_accident' => 'Lieu',
			'circonstances_accident' => 'Circonstances',
			'circonstances_accident' => 'Circonstances',
			'nature_travail' => 'Nature du travail',
			'date_transport' => 'Date',
			'heure_transport' => 'Heure',
			'destination_transport' => 'Destination',
			'intervenant_transport' => 'Intervenant',
			'sst_nom' => 'Nom',
			'sst_prenom' => 'Prénom',
			'avec_arret' => 'Avec Arrêt',
			'commentaire' => 'Commentaire',
			'nb_jours_arret' => 'Nombre de jours d\'arrêt',
			'nb_jours_soin' => 'Nombre de jours de soin',
			'auteur_login' => 'Auteur',
			'accident_conteste' => 'Accident contesté ?',
			'constat' => 'Constat ?',
			'clone' => 'Clone ?',
			'horaire_matin_debut' => 'Horaire début de matinée',
			'horaire_matin_fin' => 'Horaire fin de matinée',
			'horaire_apres_midi_debut' => 'Horaire début d\'après midi',
			'horaire_apres_midi_fin' => 'Horaire fin d\'après midi',
			'idtiersresponsable' => 'Tiers responsable',
			'idtypeaccident' => 'Type d\'accident',
			'iddeclaration_clone' => 'Declaration (clone)',
			'idetat' => 'Etat',
			'idregime' => 'Régime',
			'idservice' => 'Service',
			'idsituation' => 'Situation',
			'asouat_idasouat' => 'AS ou AT ?',
		));

ça ne marche pas non plus dans l'admin generator. Je ne vois vraiment pas où ça cloche...

J'ai regardé aussi en base, il a la même gueule que les autres.. Je ne vois vraiment pas..

[rastaferraille]

Personne n'a une idée à ce sujet ?

[Michel Rotta]

Il manque une partie du setup, celui avec les validators (si tu y a touché).

Il manque le contrôleur (l'action).

Peux-tu manuellement créer un enregistrement avec phpMyAdmin ou autre ?

Peux-tu créer un enregistrement avec les fixtures ?

Peux-tu aussi mettre le form de base (lib/form/doctrine/base/BaseXyz.class.php

[rastaferraille]

Salut,

Merci pour ta réponse, c'est bien cool.


Le form de base me semble bien. Pour l'action, il me semble que ça ne change rien puisque ça ne marche pas non plus avec l'admin generator où c'est automatisé...

Je mets en PJ les fichiers

[rastaferraille]

La suite :

J'ai pas de souci avec les fixtures, enfin je ne crois pas. Faudra que je re vérifie.

[Michel Rotta]

J'ai une mauvaise nouvelle et deux trucs.

La mauvaise nouvelle, ton code est parfait. Il n'y a aucune raison que cela ne marche pas.

Les deux trucs :

• si tu utilises sfGuard, le super utilisateur ou administrateur répond vrai à toutes les demande hasCredential, ce qui pourrait simplifier certaines demande.
• dans le fichier Declarationform.class.php lignes 121 et 127 tu as deux fois le même test sans que j'en voie l'utilité, juste une petite perte de perf.

Regardé les deux derniers fichiers. Rien de particulier.

Donc cela marche... A non ?

Juste pour me rassurer (mais je connais la réponse), avec un outils comme phpMyadmin tu peux vérifier que les champs soient bien déclaré à l'identique ?

En mode débug, tu peux récupérer la requête d'insertion, récupère et essaie là directement en SQL avec phpMyAdmin.

As-tu jeté un oeil au logs de symfony, tant dans le mode débug que dans le fichier log ?

[rastaferraille]

En fait, oui, j'avais regardé la requête en debug, les données à insérer concernant ces champs n'y sont pas...

[Michel Rotta]

Bon, déjà au moins on sait où chercher.

Le validateur est sensé retourner une date "propre".

Essaye à coup de die() de regarder la date après son passage à la moulinette du validateur.

[rastaferraille]

Merci du tuyau, pas bête l'idée du die, je ne pourrai regarder que lundi.

Un truc tout de même, j'ai déjà eu le souci, et j'avais réglé le problème avec un symfony cc. ça marche pas cette fois-ci. Je remarque aussi que j'ai pas mal de problèmes sur des champs que j'ai rajoutés après coup. Voici l'ordre des commandes que je passe après l'ajout d'un champ, dès fois que..

build-model
build-sql
insert-sql
build-forms
data-load
cc

[Michel Rotta]

Que c'est compliqué !

Code :

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

symfony doctrine:build --all --and-load

le tous en une ligne.

si tu as une base différente par environnement (ce que je recommande)

Code :

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

symfony doctrine:build --env="dev" --all --and-load

Le cc est exécuté à chaque lancement en mode débug et tu n'as pas, normalement, à t'embêter avec. Sauf si tu utilises i18n qui lui n'est pas correctement viré du cache par le système automatique au lancement (ben oui, quant à savoir pourquoi...)

[sacricri]

Encore plus propre quand tu modifies ton schema.yml :

Code :

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

1
2
symfony doctrine:generate-migrations-diff
symfony doctrine:build --all-classes --and-migrate

Que du bonheur : il fait la diff entre tes classes de modèle et ton schema et génère un ou plusieurs fichiers dans lib/migrations/doctrine/ puis regénère juste les classes et gère la migration en base sans rien supprimer (données ou table).

[rastaferraille]

Eh ben, que de bonnes choses que tu m'apprends là...
Je ne savais pas pour le coup du diff, mais c'est génial ça !
Par contre pour le build all, ça marche pas pour moi à cause d'une (ou plusieurs) clés étrangères qui me font des erreurs, du coup, je suis obligé de supprimer les tables à la main dans phpmyadmin avant de regénérer la base. C'est peut être l'ordre des tables dans mon Yaml ?

Je ne savais pas non plus qu'on pouvait utiliser une base différente pour le dev, c'est trop cool ça aussi, tu fais comment ?

[sacricri]

Pas besoin du build --all avec les migrations, juste build --all-classes ce qui évite ces problèmes

[rastaferraille]

Eh ben ça va me simplifier la vie !
Et pour les bases différentes ?

Une idée de piste : tous les champs en question sont de type time...

[Michel Rotta]

Ca se joue dans le fichier database.yml.

En plus de

Code :

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

1
2
3
4
 
All:
  Doctrine:
    ...

Tu peux ajouter devant des modifications pour chaque environement.

Code :

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

1
2
3
4
5
6
7
8
9
 
Dev:
  Doctrine:
    Param:
      Dsn: ...
 
All:
  Doctrine:
    ...

Mon idée est d'avoir 5 a 6 bases.

Les bases DOIVENT pouvoir être régénérée par un build --all

Les bases DOIVENT accepter les fixtures pour les tests et donc toujours redémarrer à l'identique.

env et test doivent pouvoir être réinitialisée très régulièrement, test peut l'être plusieurs fois dans une scéance de test.
inter va permettre de générer les diff et se trouve dans un autre environnement de dev.
testprod va permettre de tester les diff et se trouve dans un environnement de semi exploitation. Elle peut être utilisée pour réinitialiser l'environnement inter
prod la finale qui est la seul visible par l'utilisateur finale. Dans certain cas ont peut rajouter une prodtest qui permet aux utilisateurs finaux de faire des test (la testprod est plutôt pour les développeurs et les validateurs).

Mais bon, tous dépend de l'importance du projet.

[rastaferraille]

Merci pour toutes ces précisions !

Et en mettant à jour symfony, je me dis, si ça se trouve le souci vient de là. Y'a une commande à faire où faut retélécharger le source ?

[Michel Rotta]

Tous dépend de la manière dont tu as fais l'installation.

[rastaferraille]

OK, merci, donc à la mano pour moi !

Une question quand même, en mode "debug" c'est la même chose que dev ?

[sacricri]

OK, merci, donc à la mano pour moi !

Une question quand même, en mode "debug" c'est la même chose que dev ?

En fait, le mode debug est activé en dev mais tu peux tout aussi bien l'activer en prod ou en test :

Code :

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

1
2
// fichier web/backend_dev.php par exemple
$configuration = ProjectConfiguration::getApplicationConfiguration('backend', 'dev', true);

Le true active le mode debug

Pour les sources, je travaille à la mano perso et j'ai une petite technique pour mettre à jour :

Dans le répertoire de mes projets, j'ai un répertoire SOURCES (qui contient les versions 1.2.11, 1.4.3 et 1.4.4) et j'ai un lien symbolique au niveau du répertoire des projets qui pointe vers la dernière version soit :
symfony12 -> SOURCES/symfony-1.2.11
symfony14 -> SOURCES/symfony-1.4.4

Quand je mets à jour, je dl le dernier tar.gz, je le détar dans SOURCES et je modifie le lien symbolique. Il ne reste plus qu'à clear le cache des projets.

[rastaferraille]

Merci JP ! je fais la maj et je vous tiens au courant !