Discussion :

[Himloy]

Salut à tous,

J'aurai une question, plutôt méthodologique que technique concernant les formulaires.

Je possède un formulaire avec un champ date très classique.

Code :

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

1
2
<?php 
->add('date','date', array('label'=> 'Date','format' => 'dd MM yyyy'))

L'histoire, c'est que je souhaite mettre un bouton en dessous de ce champ pour rajouter un autre champ date, comme ça l'utilisateur pourra ajouter et choisir 3,4 dates.

Maintenant, étant débutant dans le domaine, je ne vois pas comment récupérer ces dates pour les mettre dans la base de données.
Je pense que c'est plus une question php que symfony2, mais défois qu'il y ait un truc simpa dans ce framework pour ça... je suis preneur.

Merci d'avance

[Parmifer]

Salut à toi !

Bon déjà si tu veux plusieurs champs de dates tu peux tout simplement les multipliers en donnant des noms du genre date1, date2, date3, etc...

Ensuite, pour tout ce qui est relatif aux bases de données, tu as Doctrine qui marche bien (et qui est très utilisé).

Je te laisse allez voir la documentation ici : http://symfony.com/fr/doc/current/book/doctrine.html

[arnooo999]

Bonjour,

je souhaite mettre un bouton en dessous de ce champ pour rajouter un autre champ date, comme ça l'utilisateur pourra ajouter et choisir 3,4 dates.

Pour ça tu as le type de formulaire collection:
http://symfony.com/fr/doc/current/co...llections.html

Le formulaire n'est que le reflet de ta modélisation, si tu as +sieurs colonnes date dans ta table, ce n'est pas adapté.

A priori il te faut une entité "Date" composé d'un attribut de type Date et une relation OneToMany avec ton entité principale.

[Parmifer]

Mince, j'avais mal lu, désolé pour les bétises alors.

Cela dit, tu peux toujours allez voir Doctrine.

[Himloy]

Salut Parmifer merci pour ta réponse,

alors, pour les champs date j'ai un ptit truc en place en ajax:

Code :

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

1
2
3
4
5
function ajout_date(i) {
var i2 = i + 1;
document.getElementById('date'+i).innerHTML = '<input type="date" name="date'+i+'"></span>';
document.getElementById('date'+i).innerHTML += (i <= 30) ? '<br /><span id="date'+i2+'"><a href="javascript:ajout_date('+i2+')">Ajouter une date</a></span>' : '';
}

Concernant doctrine, c'est ce que j'utilise, j'ai mes entités en place en php, le tout en classe avec les liens en @ORM, bref j'ai essayé de respecter au maximum les conventions de Symfony.

Du coup, je pensais à...

_________

Okay, apparition de réponses dans ma prévisualisation, merci pour les nouveaux messages.

Bonjour arnooo999, merci pour ta réponse,

Donc faut que je repense ma table, avec ce nouveau besoin, c'est noté.

Du coup, si j'ai bien compris, je vire mon champ date de l'entity, je fais une nouvelle entité Date avec un onetomany et le nouveau formulaire DateType.
j'imbrique le formulaire dans mon formtype avec un

Code :

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

$builder->add('dates', 'collection', array('type' => new DateType(), 'allow_add' => true));

Avec le allow_add à true pour en ajouter autant que je veux.
Je met mon morceau d'ajax en le bidouillant, ou je reprend celui de la doc que tu m'as fourni.
Mon nouveau bouton d'ajout de date va donc créer un nouveau formulaire à l'intérieur du miens, et je peux en faire plusieurs.


Par contre, j'ai un autre formulaire qui permet de modifier celui ci ( FormEditType ). Je conçois que je dois le bidouiller également. Mais une petite question, cela ne posera pas de problèmes d'avoir plusieurs dates si par exemple je veux en modifier une seule ?

[HS]
Pendant mes recherches, je pensais à l'array en php pour essayer de fusionner ces dates, du coup simple question de curiosité,penses tu que le data transformer pouvait répondre à ce problème?
[/HS]

Merci d'avance

[arnooo999]

Pendant mes recherches, je pensais à l'array en php pour essayer de fusionner ces dates, du coup simple question de curiosité,penses tu que le data transformer pouvait répondre à ce problème?

On pourrait simplement sérialiser ces dates pour les stocker dans la BDD, ça pourrait se faire dans les getter et setter

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
 
/**
*@ORM\Column(type="text")
**/
protected $dates;
 
protected $unserializedDates;
 
public function getDates(){
 if (null===$this->unserializedDates){
     $dt=unserialize($this->dates);
     $this->unserializedDates=unserialize($this->date);     
 }
 return $this->unserializedDates;
}
 
public function setDates(array $dates){
$this->unserializedDates=$dates;
$this->dates=serialize($dates);
}

dans ce cas ton formulaire aura un champ collection de type "date" (le type natif de symfony)

Code :

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

1
2
 
$builder->add('dates', 'collection', array('type' => 'date', 'allow_add' => true));

Le probleme étant qu'avec cette modélisation, il n'est pas possible de faire des requetes sur les dates puisqu'au final pour la BDD c'est un champ texte (pas possible de requeter les lignes ayant une date comprises entre tel date et tel date).
Ce serait sans doute une solution viable avec une Base de données noSql (MongoDB)

Par contre, j'ai un autre formulaire qui permet de modifier celui ci ( FormEditType ). Je conçois que je dois le bidouiller également.

Est-ce vraiment utile d'avoir 2 formulaires pour la même entité?
éventuellement tu peux passer des options si quelques champs différent

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
//MyEntityType
public function buildForm($builder,$options){
  $builder->add('nom');
  if($options['mode']=='create'){
     $builder->add('something');
  }
}
public function setDefaultOptions($resolver){
   $resolver->setDefaults(array('mode'=>'update');
}

dans le controlleur

Code :

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

1
2
 
$this->createForm(new MyEntityType,$entity,array('mode'=>'create');

Mais une petite question, cela ne posera pas de problèmes d'avoir plusieurs dates si par exemple je veux en modifier une seule ?

Ton formulaire s'affichera en édition avec les dates préremplies et éditable, il n'y a pas de soucis.

[Himloy]

Bonjour,

Alors, okay je comprend l'intérêt et le défaut du serializer.

Pour le deuxième formulaire, je bouge quelques champs entre l'ajout et la modification(genre un nouveau champ modif, un remove de la date d'ajout, ce genre de truc)
J'avoue que ton idée est plus optimisée, je l'utiliserais dans mon nouveau formulaire datetype, pour un champ.

Concernant le parcours:
Donc j'ai construit mon form, viré le champ date de l'ancien entity, fait une nouvelle entité Date comprenant logiquement le champ date.
Ajouté le champ collection dans le FormType avec le DateType.

Il s'affiche tout bien, j'ai bidouillé l'ajax pour en afficher plusieurs, la vie est belle.

J'ai juste un petit "hic" concernant la validation.
Je me prend un spl_object_hash() expects parameter 1 to be object, array given lors du flush().
Si je comprend bien, mon formulaire imbriqué est compté comme un objet, sauf que je lui balance un array. Mais c'est une collection, donc une liste d'objets dans un array. La méthode serait de transformer ma liste en objet ?

J'ai vu que c'est une erreur assez courante, mais les solutions ne sont pas très claires...

Merci d'avance

[arnooo999]

Est-ce que tout est bien configuré:

- cache vidé (y compris apc)
- config de la relation ( Date en ManyToOne vers ton entité + inverse side de ton entité vers Date en OneToMany)
- table date avec champs id, date, foreign_key_de_ton_entité
- methode addDate et removeDate dans ton entité

- cascade persist sur cette relation
- reverse et owning side OK ( http://docs.doctrine-project.org/en/...n-mapping.html )

[Himloy]

Okay donc j'ai fait une/des erreur(s).

Merci pour la checklist je regarde ça.

[Himloy]

Okay, donc j'ai vraiment m***é sur la config.

Merci pour la check list, j'ai corrigé tous les ptits bugs, la vie est belle, j'ai crée mon formulaire, les dates se mettent dans la table même si j'en fais trouzemille, comme il faut.

J'aurai une autre question(si ça ne gène pas bien sur), pour le twig, j'ai actuellement un {{ form_row(form.dates) }} pour afficher le formulaire DateType. Est ce qu'il est possible de détailler chaque élément de ce formulaire ?
Je veux dire faire un {{ form_row(form.dates.monchamp1) }}, {{ form_row(form.dates.monchamp2) }}... pour faire un peu de mise en forme.

Une dernière question un peu plus technique.

J'ai un champ dans la table date, appelons le "nom".
Le but:
nom est à nullable=true au début. Donc quand l'utilisateur rempli le formType, il ne voit pas ce champ.
Cependant, un deuxième utilisateur va modifier ce formulaire. Lui, véra le champ nom et pourra le remplir.

La méthode:
Mon FormEditType sert notamment à ça ( j'utilise un parent::buildForm($builder, $options);), sauf que ce champ est dans DateType, du coup je n'arrive pas à lui faire comprendre que ce champ doit s'afficher seulement dans le FormEditType.
Donc, je me dis, et si j'installe ce que tu m'as conseillé.

J'ai donc :

Code :

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

$form = $this->createForm(new EntityType, $entity, array('mode'=>'create'));

dans ajout, et un :

Code :

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

$form = $this->createForm(new EntityEditType, $entity, array('mode'=>'update'));

dans mon action de modification

Dans le DateType j'ai mis un :

Code :

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

1
2
3
        if($options['mode']=='update'){
            $builder->add('nom');
         }

Et donc dans les options par défaut j'ai ajouté le :

Code :

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

1
2
        $resolver->setDefaults(array(
            'mode' => 'update'

Si j'ai bien compris ta méthode.
Sauf que, le 'mode' n'est pas répertorié dans les options, je prend donc un The option "mode" does not exist.

Du coup, est ce que j'ai juste oublié de mettre un use Machin\QuifaitQue\CaMarche; au début?
Ou c'est un peu plus technique (en prenant en compte que j'ai pu mal comprendre bien sur)...
(Je reconnais que je n'ai cherché longtemps avant de post, mais je suis déjà en heure sup, et revenir demain matin en évitant de galérer la journée..., donc navré !)

En tout cas, merci de ton aide !

[arnooo999]

Pour personnaliser le twig d'un form collection, tu peux utiliser le form_theming
c'est souvent demandé dans ce forum:

http://www.developpez.net/forums/d14...lisation-twig/
http://www.developpez.net/forums/d14...ons-manytoone/
Dans ce lien on parle d'une autre technique de personalisation, mais depuis SF 2.1, je prefere le form theming
http://www.developpez.net/forums/d13...res-imbriques/

Pour le probleme de passage d'option, d'aprés ton code tu passes l'option "mode" à EntityType, mais si je comprend bien c'est sur DateType que tu l'as défini
Il y a une option "option"(!!) dans le type collection (http://symfony.com/fr/doc/current/re...n.html#options),
Donc il faudrait
-> autoriser l'option "mode" sur EntityType
-> passer cette option au champ collection dans le buildForm de EntityType

Code :

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

1
2
3
4
 
function buildForm($builder,$options){
$builder->add('date','collection',array('type'=>new MyDateType,'option'=>array('mode'=>$options['mode']));
}

Mais en fait ce n'est pas vraiment ça que tu veux.
Ce qu'il faut c'est ajouter un champ au formulaire de date en fonction de l'entité MyDate et pas en fonction de l'entité parente.
Pour ça il faut plutôt se tourner vers les FormListener
http://symfony.com/fr/doc/current/co...nderlying-data
Donc dans le buildForm de MyDateType tu ajoutes un listener , une fonction qui va analyser les données du form date, et si elle n'existe pas ou que l'id n'est pas renseigné, alors on ajoute un champ au formulaire

NB cela signifie que coté twig il faut gérer les deux cas (avec ou sans le champ supplémentaire),
occupe toi d'abord du listener puis aprés de la personalisation html

[Himloy]

Hmm, la fameuse page dynamic_form_modification du cookbook...

Cette page est assez abstraite pour moi, j'en ai déjà besoin pour remplir des champs dynamiquement suivant un choix dans une liste déroulante ( genre récupérer l'adresse du client lors de sa sélection), je l'ai déjà retournée dans tous les sens, c'est un classique qui a déjà fait perdre beaucoup de cheveux, mais en vain.
Du coup j'en ai besoin aussi pour ça, yepee.

Donc je garde les modes dans un coin pour une autre occasion et je replonge là dedans, okay.

D'ailleurs si tu as un tuto assez accessible sur les champs dépendants d'autres champs, je suis preneur, je pense avoir déjà tout retourné sur le net, mais des fois que...

Concernant le twig, c'est plutôt vaste, je m'attendais juste à trafiquer dans le code source pour faire un display:none sur le champ. Je vais voir ça.


On s'éloigne du sujet, en tout cas merci de ton aide.