[sf 1.4.x] sfWidgetFormDoctrineJQueryAutocompleter et is_empty [Résolu]

[erictomcat]

bonjour,
j'aimerai savoir si dans un filtre générer par l'admin generator il y a moyen d'avoir le checkBox is_empty quand on a transformé le champ en sfWidgetFormDoctrineJQueryAutocompleter ?

[PeytaWodka]

Essai d'ajouter l'option with_empty => true.

[erictomcat]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
public function configure()
  {
    sfContext::getInstance()->getConfiguration()->loadHelpers(array('Url'));
 
    $this->widgetSchema['user_id']->setOption('renderer_class', 'sfWidgetFormDoctrineJQueryAutocompleter');
 
    $this->widgetSchema['user_id'] = new sfWidgetFormDoctrineJQueryAutocompleter(
      array(
        'with_empty'=> true,
        'model' => "sfGuardUser",
        'url'   => url_for("@ajax_username")
      ), array('size' => 25)
    );
  }

j'ai essayé aussi avec add_empty => true, mais j'ai le même message d'erreur:

Code :

1
2
500 | Internal Server Error | InvalidArgumentException
sfWidgetFormDoctrineJQueryAutocompleter does not support the following options: 'with_empty'.

[Michel Rotta]

Quel est l'intérêt de la ligne

Code :

$this->widgetSchema['user_id']->setOption('renderer_class', 'sfWidgetFormDoctrineJQueryAutocompleter');

placée là ?

Elle est normalement annulée par la suivante.

Regarde dans le code du widget, tu devrais y trouver des informations autour de la méthode __construct()

[erictomcat]

aucune idée pour la ligne, elle y était dans l'exemple que j'ai trouvé.
Et si je me souvient bien, ça plante si elle n'y est pas.

[Michel Rotta]

Ce qui m'étonne c'est sa présence avant la création du widget. Dans mes souvenir le fait de déclarer un nouveau widget supprimait les options précédemment définies. Je suis manifestement dans l'erreur.

Pour revenir à la question d'origine, je ne pense pas que cela puisse marcher.

En effet, ton widget est un sfWidgetForm et pas un sfWidgetFormFilter. Il n'embarque donc aucun code pour générer la box.

[erictomcat]

arfeu, oui.
il existe un form filter qui ferait la même chose ?

[Michel Rotta]

Dés que tu l'auras écrit et posté en plugin, il existera !

Non, à ma connaissance, il n'existe pas et Google ne m'a pas aidé sur le coup.

Et je n'ai pas réellement démonté de sfFormFilter... pour voir la différence, d'autant que le sfWidgetFormDoctrineJQueryAutocompleter n'est pas le widget le plus simple qui existe.

En fait, je me demande si tu n'aurais pas intérêt à utiliser un simple widget sfFormFilterInput que l'utilisateur y colle un bout du texte recherché pour trouver ses enregistrements, je ne vois pas trop l'absolue nécessité, dans un filtre, d'une sélection par liste, et si tu regardes les widgets filtre existant, sensio non plus ne semble pas y voir une chose importante.

[erictomcat]

effectivement, a bien y réfléchir, l'intérêt est minime.
En faites le but initial était de remplacer un select trop long qui plantait l'affichage (time excedeed).
Je pense remplacer ce champ par un input text, ça sera tout aussi bien.

[Michel Rotta]

[erictomcat]

arfeu sauf que c'est pas si simple de remplacer un select par un text.
Dois je créer un getter spécifique pour aller chercher via le nom la liste des id ?

[Michel Rotta]

Je parie que le texte de la combo n'est pas dans la table que tu veux filtrer...

[erictomcat]

dans un schéma simple:

Code :

1
2
3
4
5
6
7
8
 
table1:
  columns:
    name: string(255)
    responsable_user_id: integer
  relations:
    user:
      class: sfGuardUser

generation d'un module admin.
par défaut le champ responsable_user_id dans le filtre est un select.
Sauf qu'avec 10000 users, j'ai un time exceedeed.

je cherche a le remplacer par un champ text tout bête

[Michel Rotta]

Et je suis près à parier que tu es dans le cadre d'un formulaire auto-généré...

Tu peux essayer de changer la méthode du modèle destinée à récupérer les données. De manière à ce que la méthode récupère sur les deux tables.

Mais j'ai (beaucoup) de doutes.

Si non, tu es à la limite de ce que sait faire l'auto génération.

Si ton application est stable, tu peux toujours récupérer le module auto généré dans le cache, en faire un vrai module et le modifier (au niveau du code) pour prendre ton besoin en compte.

[erictomcat]

c'est la page index généré par l'admin-generator.
ça serait pas plus simple de considérer ce champ comme un champ étranger et créer un champ filtre de toute pièce?
j'ai fait un truc dans ce genre pour filtrer des données par pays alors que la table ne gérait que les villes.

[Michel Rotta]

C'est possible.

J'utilise très peu les formulaires auto-généré, je manque un peu d'expérience dés que l'on sort des routes préétablies.

[erictomcat]

en m'appuyant sur l'exemple trouve ici

j'ai modifier mon fichier FormFilter.class.php

Code :

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
 
public function configure()
{
    $this->widgetSchema['usertxt']=new sfWidgetFormFilterInput();
    $this->validatorSchema['usertxt']      = new sfValidatorString();
}
 
public function getFields()
 {
   return array_merge(array('usertxt' => 'responsable'), parent::getFields());
 }
 
 public function addUsertxtColumnQuery(Doctrine_Query $query, $field, $value)
 {
   $fieldName = $this->getFieldName($field);
   //var_dump($value);
   //die;
   if ( $value )
   {
     $a = $query->getRootAlias();
     $query->leftJoin($a.'.user g')
        ->addWhere('g.last_name like ?',$value.'%');
   }
 
   return $query;
 }

et bien entendu, j'ai rajouté dans le fichier generator.yml mon nouveau champ.

La ou ça coince c'est que la valeur $value est egal à Array !!!
quelqu'un a une idée ?

[Michel Rotta]

Normal (?). Je suppose que c'est juste une copie de la propriété values du form. Je m'étonne juste qu'il l'ait appelé value et pas values.

Regarde avec un var_dump ce qu'il y a dedans. Et récupère dans le tableau l'information qui te vas bien. Possible aussi qu'il n'y ait qu'une information pour un string alors qu'il y en aurait plusieurs pour un select.

[erictomcat]

bein le var_dump de $value m'affiche:

Code :

string 'Array' (length=5)

[Michel Rotta]

Bon, j'ai un peu creusé.

First. Dans les autres méthode, le nom de la variable est bien $values avec un "s", ce qui dans les conventions symfony laisse entendre que tu es sur un tableau.

Second. Effectivement, $values devrait bien être un array, quoique. En effet, il semblerait que suivant les cas, il soit juste une valeur (et dans ce cas c'est $value), dans d'autres c'est un tableau dont les retours sont différent d'une méthode add à l'autre.

Je suppose que les widgets particulier sfWidgetFormFiterXxxx y sont pour une partie. Vu que tu te base sur un sfWidgetFromFilterInput tu devraits avoir un tableau avec deux entrées, un is_empty et un text.

Third. Tu rajoutes très justement une entrée à la méthode getFields(), mais le tableau est à l'envers, le nom du champ devrait être avant le type. De toutes les manières, on s'en fiche ! En effet, si le nom de la colonne n'est pas un des nom des champs de l'objet de base du filtre, il ne regarde jamais l’existence du type.

Ton code pourrais, corrigé, ressembler à ceci :

Code php :

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
#form filter (non testé)
public function configure()
{
    $this->setWidget( 'responsable', new sfWidgetFormFilterInput( array( 'with_empty' => false ) ) );
    $this->setValidator( 'responsable', new sfValidatorString( array( 'required' => false ) ) );
}
 
public function getFields()
 {
   return array_merge(array('responsable' => 'text'), parent::getFields());
 }
 
 public function addResponsableColumnQuery(Doctrine_Query $query, $field, $values)
 {
   $fieldName = $this->getFieldName($field);
   //var_dump($value);
   //die;
    if (is_array($values) && isset($values['text']) && '' != $values['text'])
   {
     $a = $query->getRootAlias();
     $query->leftJoin( $a.'.user g' )
        ->addWhere( 'g.last_name like ?', $values['text'] . '%' );
   }
 
   return $query;
 }

Pour $value(s), c'est un peu le flou. En fait il renvoie la valeur 'responsable' qui est dans la propriété values du filtre (propriété qui est un objet). Je suppose (mais je ne suis pas descendu suffisamment loin dans le code du sfFormFiltreDoctrine) que le type de donnée dépend du type de champ et/ou du type de widget. En modifiant le champ pour le mettre de type text dans getFields() ce qui le met conforme au widget choisi, je pense qu'on devrait être près de la vérité.

Ensuite tu peux toujours faire un var_dump( $this->values ) qui pourrait vérifier à la source.

Si tu as toujours un truc du genre 'responsable' => 'array' dans la propriété value, c'est qu'il y a un gros problème et qu'il va falloir démonter les Widgets et les validateurs