Discussion :

[amalec78]

Bonjour,

Voila j'ai un petit problème, je cherche a récupérer un id dans ma class form.

Voici 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
 
class CandidateDegreeForm extends BaseCandidateDegreeForm
{
 
  public function configure()
  {
 
    $idD = $this->object->id;
    if($idD)
    {
      $q = Doctrine::getTable('CandidateDegree')->find($idD);
      $query = Doctrine::getTable('CandidateSchool')->createQuery('sc');
      $query->where('sc.candidate_id='.$q->getCandidateId());
 
      $this->widgetSchema['candidate_school_id'] = new sfWidgetFormDoctrineChoice(array('model' => 'CandidateSchool', 'add_empty' => true,'query'=>$query));
    }
  }
}

Au fait dans mon formulaire j'ai toujours un id candidat (que je connais d'avance). Et cette id que j'aimerai récupérer pour pouvoir faire une liste déroulante filtrer.

La actuellement mon code me permet de récupérer l'id de l'enregistrement. Ce qui fonctionne en édition mais pas dans le cas d'un nouveau enregistrement.

Alors si quelqu'un a déjà fait cela, je suis preneur.

Au pire des cas, je vais devoir le faire en ajax.

Merci d'avance pour votre aide.

[Michel Rotta]

Lors de la création d'un enregistrement, il n'y a pas d'Id dans l'objet data.

L'Id n'"apparait" qu'une fois l'objet enregistré pour la première fois sur le disque. En effet, c'est la base de données qui, généralement, attribue l'Id. Et la base de donnée n'est pas au courant de l’existence potentiel de cet enregistrement avant qu'il ne soit créé (MySql avec une boule de cristal ? non, ceci n'existe pas).

Tu as donc trois solutions (a priori) :

Créer l'enregistrement avec un minimum de champ et après un premier enregistrement, renvoyer la page normal de modification avec le tout (l'id existera).

Créer l'enregistrement et attribuer toi même l'Id à partir d'une procédure qui t'es propre. Plus d'attente mais le risque de perdre un numéro.

Lors de la demande de création, commencer par créer l'enregistrement en base de données et l'afficher en modification (l'id existera). Par contre, il va falloir gérer ceux qui auront été abandonné entre la demande de création et la sauvegarde.

Personnellement j'utilise la méthode 1 le plus souvent possible.

[amalec78]

Ok. Je me suis mal fait comprendre. Au fait dans ma table j'ai deux champs.
Id = clef primaire (celui bien sur on ne le connait pas)
idCandidat = mais celui on le connais via l'url.

ET je voudrai faire un traitement avec l'idcandidat de le form. Donc je chercher a le récupérer. Je pense que je vais le faire avec la session.

[Michel Rotta]

Donc tu as un paramètre transmis au contrôleur que tu voudrais faire passer à form pour qu'il l'utilise dans sa méthode configure() ?

[amalec78]

Oui. Donc j'ai fait comme ceci :

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
 
class CandidateDegreeForm extends BaseCandidateDegreeForm
{
 
  public function configure()
  {
 
    $user = sfContext::getInstance()->getUser();
    $idC = $user->getAttribute("idCandidate");
 
    $query = Doctrine::getTable('CandidateSchool')->createQuery('sc');
    $query->where('sc.candidate_id='.$idC);
 
    $this->widgetSchema['candidate_school_id'] = new sfWidgetFormDoctrineChoice(array('model' => 'CandidateSchool', 'add_empty' => true,'query'=>$query));
 
  }
}

Et ca fonctionne.

[Michel Rotta]

C'est une bonne solution. Elle n'a qu'un défaut, si une personne ouvre deux fenêtre dans une même session, il ne pourra avoir qu'une valeur pour idCandidate dans son paramètre. Mais il n'y a pas d'autre possibilité avec cette technique, qui, hors ce problème, est excellente.

Par contre, tu ne devrais pas avoir de requête dans un form. Il serait bon de la déporter dans un objet du modèle, ici probablement : CandidateSchoolTable.class.php et d'y faire référence depuis le form. Ceci pour préserver la séparation des couches que l'objet form met déjà un peu à mal, rien ne sert de l'aider

[Nico_F]

J'approuve la solution de Michel par contre je me permet de rebondir sur sa remarque concernant la séparation des couches du modèle dont j'ai un exemple similaire.

En quoi la solution suivante :

Code :

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

1
2
3
4
5
6
//class EventForm
$this->widgetSchema['brand_sales_assistant_id'] = new sfWidgetFormDoctrineChoice(array(
			'model' => $this->getRelatedModelName('Profile'),
			'method' => 'getUser',
			'query' => Doctrine_Query::create()->select()->from('profile p')->where('p.entity_id = 2'),
		));

est-elle moins "bonne?"/"performante?" que cette solution ?

Code :

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

1
2
3
4
5
6
//class EventForm
$this->widgetSchema['brand_sales_assistant_id'] = new sfWidgetFormDoctrineChoice(array(
			'model' => $this->getRelatedModelName('Profile'),
			'method' => 'getUser',
			'query' => $this->getObject()->getTable()->getBrandSalesAssistant() // <-- EDIT (diantre j'ai tapé mon getTable à l'aveuglette et ça fonctionne comme ça ? Mais elle est ou cette méthode getTable() Pas dans ma base de classe en tout cas !) 
		));

Est-ce uniquement pour le principe de dire que l'on place les choses à leur place (donc pour des questions de lisibilité, maintenance etc.) ? Ou est-ce qu'il y a des traitements supplémentaires ou des ralentissements par rapport à l'autre méthode ?

[Michel Rotta]

En fait la méthode la plus proche du MVC doit être imperceptiblement plus lente... Par contre elle présente l'avantage de plus de facilité à la maintenance, plus lisible. Et si tu modifies la structure de la table, tu n'a qu'un objet à modifier, le reste ne devrait pas être directement impacté.

Pour ta méthode, si tu regardes ton objet tableBase tu vas voir qu'il est lui même enfant de sfDoctrineRecord, enfant de Doctrine_Record et qu'il y a un paquet de méthodes qui découlent de Doctrine_Record...