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 ?
Version imprimable
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 ?
Essai d'ajouter l'option with_empty => true.
j'ai essayé aussi avec add_empty => true, mais j'ai le même message d'erreur:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Code:
2
Quel est l'intérêt de la ligneplacée là ?Code:$this->widgetSchema['user_id']->setOption('renderer_class', 'sfWidgetFormDoctrineJQueryAutocompleter');
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()
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.
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.
arfeu, oui.
il existe un form filter qui ferait la même chose ?
Dés que tu l'auras écrit et posté en plugin, il existera ! :mouarf:
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.
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.
:ccool:
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 ?
Je parie que le texte de la combo n'est pas dans la table que tu veux filtrer...
dans un schéma simple:
generation d'un module admin.Code:
2
3
4
5
6
7
8table1: columns: name: string(255) responsable_user_id: integer relations: user: class: sfGuardUser
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
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.
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.
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.
en m'appuyant sur l'exemple trouve ici
j'ai modifier mon fichier FormFilter.class.php
et bien entendu, j'ai rajouté dans le fichier generator.yml mon nouveau champ.Code:
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
La ou ça coince c'est que la valeur $value est egal à Array !!!
quelqu'un a une idée ?
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.
bein le var_dump de $value m'affiche:Code:string 'Array' (length=5)
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:
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
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 :aie:
var_dump de $values donne:donc forcément le codeCode:string 'Array' (length=5)
renvoie faux et aucun filtre n'est appliqué :(Code:if (is_array($values) && isset($values['text']) && '' != $values['text'])
Le problème est en amont.
As-tu un debuger installé pour le PHP ? Si oui, essaye de tracer la variable depuis le passage dans le validateur.
malheureusement non, j'a deja essayer d'installer x-dbug, jamais réussi a comprendre comment ça fonctionnait :(
si tu en connait un autre d'approche plus facile, je suis preneur :)
Si tu installes sur ton poste (sous windows) la dernière version de WAMP et la version 6.9 de netbeans, tu n'as rien de particulier à configurer.
Dans l'EDI tu choisis le point d'arrêt et tu exécutes ton appli en mode débogue. Et tu as accès au code en ligne par ligne avec consultation des valeurs des propriétés des objets et des variables. Que du bonheur. Et, en prime, lors de messages d'erreur, tu as le stak de php qui est affiché ce qui permet d'avoir beaucoup plus d'informations sur l'erreur.
j'ai wamp et netbeans, plus qu'a me plonger dans la doc :)
bon bein faut le savoir mais le widget sfWidgetFormFilterInput n'accepte comme validateur que sfValidatorPass.
Et la effectivement on se retrouve avec un array['text'=>,'is_empty'=>].