Discussion :

[mantex]

Bonsoir,

J'aimerai savoir comment attribuer une valeur par défaut dans un form.

J' ai comment changer les labels et desactiver une champs dans le generator.yml mais pas modifier la valeur par défaut.

Dans mon cas il s' agit des champs type de table héritées.

Ex:

Code :

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

1
2
3
4
5
6
7
8
9
 
 
Customer:
  actAs: { Timestampable ~ }
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: CUSTOMER

[Michel Rotta]

Dans un module d'administration ?

[mantex]

Oui !

[Michel Rotta]

Est-ce que les valeurs par défaut que tu veux mettre en place sont vraies dans tous les cas ?

Si oui, le plus simple serait de les mettre directement dans le shema.yml.

[mantex]

Non tu penses bien.

Pour le formulaire des consultants (new) j' aimerai que champs type soit d' office à la valeur consultant car j' aimerai le désactivé.

Idem pour les clients.

Tu as une idée pour faire cela ?

[Michel Rotta]

Tu dois avoir un champ qui prend une valeur différente en fonction du fait que tu traites un client ou un consultant, on va l'appeler "type". Le champ à modifier sera le champ "amodif"

Dans l'objet du modèle lib/model/doctrine/maTable.class.php
tu va rajouter deux méthodes :

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
 
public function getTypeSpe( $value )
{
   if (1 == $value) // le client
   {
      parent::__set( 'amodif', 'taratataClient');
   }
   elseif ( 2 == $value ) // le commercial
   {
      parent::__set( 'amodif', 'taratataCommercial');
   } // a toi de vois si tu veux un else ou pas.
   parent::__set( 'type', $value );
   return $this;
}
 
public function getTypeSpe()
{
   parent::__get('type');
}

Il faut encore créer un form spécifique pour l'action, où dans la méthode configure() tu vas substituer la le widget et le validator sur "type" par un identique sur "typeSpe".

Et dans le generator.yml, pour l'action édition, tu vas préciser que le form à utiliser est le nouveau form ci-dessus modifier.

Propre et net.

[mantex]

Merci de ta réponse mais ce n' est pas un chouya lourd pour un simple champs hidden à fixer ?

[Michel Rotta]

En fait ... non.

D'abord, le champ ne doit pas être hiden, il n'a aucun intérêt à le faire transiter par la requête.

Ensuite on respecte parfaitement le fonctionnement MVC, la couche M s'occupe de gérer les données en fonction de ce que tu demandes.

La couche C (le form) s'occupe de mettre en place les données du formulaire.

On configure le générateur pour qu'il utilise le bon formulaire.

On maintiens la séparation des couches, le champ, peut être réutilisé ailleurs, et on utilise le générateur d'administration. Plus simple je ne vois pas.

Par contre, tu pourrais générer un module (pas un d'amin) et tous traiter dans la couche C. Mais alors, plus de générateur et un traitement des données dans la couche C. Pas propre...

[mantex]

en relisant la doc j' ai trouvé cela pour redéfinir un champs sur une liste de valeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
// lib/model/doctrine/JobeetJobTable.class.php
class JobeetJobTable extends Doctrine_Table
{
  static public $types = array(
    'full-time' => 'Full time',
    'part-time' => 'Part time',
    'freelance' => 'Freelance',
  );
 
  public function getTypes()
  {
    return self::$types;

Ce qui sous entend que cette liste de valeur peut contenir une seule valeur n' est ce pas ? En fixant cela pour mes deux classes, cela peut régler mon pb, non ?

[Michel Rotta]

Je ne sais plus ce que tu veux faire, mais ceci ne répond pas à la question initial.

[mantex]

En fait c 'est assez simple.

J' ai 2 formulaires admin pour mes modules customer et consultant qui utilisent tout les deux une classe héritée de sf-guard-user.

J' ai donc un champs type qui prends l' une ou l' autre valeur.

il permet donc de distinguer les deux. Mais je ne veux pas que ce champs soit visible par les utilisateurs.

Donc dans le formulaire d' ajout de consultant, le champs type doit être masqué et fixé a CONSULTANT et CUSTOMER pour l' ajout de client dans le module customer.

Si je surcharge le champs à un tableau d' une seul valeur , je devrait pouvoir contourné le problème non ?

Il me suffira ensuite de désactivé le champs dans mes function configure()
pour qu' il ne soit pas visible par les utilisateurs.


Qu' en penses tu ?

[Michel Rotta]

Pour la fin, oui.

Pour le début non. C'est plus simple que ce que je t'ai donné...

Vu que tu utilises des tables héritée, il faut utiliser les form généré pour les tables hérité. Ils ont dans leur code tous ce qu'il faut pour utiliser un objet hérité qui, lui, est capable de mettre la bonne valeur dans le champ type...

Donc, en fait, dans ce cas là, tu n'as rien à faire. Tu génères tes deux administration et, soit tu unset le champ dans le form, soit tu le vires depuis le fichier de config de l'admin.

[mantex]

ahh ok, mais en fait j' ai lancé la génération de mes admin avant d 'introduire la notion d' héritage dans mon schema.

Si je relance la génération des admin, quel est le comportement ? Cela va t-il écraser mes form ou seulement relire le schéma ?

J' ai commencé à modifier l' ordre des champs et ceux dont j' ai besoin dans l' affichage des vues.

[Michel Rotta]

Je supprimerais les modules admins existant (quitte à garder une sauvegarde) et je regénèrerais de rien.

[mantex]

c' est bien ce que je pensais.. par contre au tout début j' avais crée un module rapidement pour tester mais j'ai pas trouvé la commande pour le supprimer.

J' ai supprimer le répertoire de mon module, régénéré celui ci et fait un unset du champs type dans ma fonction configure().

Miracle, la valeur par défaut bien est ajoutée lorsque je soumet le formulaire new.

[Michel Rotta]

En informatique, il y a la pratique et la théorie.

La théorie c'est quant on sait pourquoi cela ne marche pas.

La pratique c'est quant on ne sais pas pourquoi cela marche

Tu fais de la pratique

Bon, si tous est OK, un petit coup de et tout est bon

[mantex]

En informatique, il y a la pratique et la théorie.

La théorie c'est quant on sait pourquoi cela ne marche pas.

Oui peut être mais dans tous les projets c 'est la pratique au finale qui permet de sortir le projet. Symfony n' est pas très accessible car il y a plein de notions évidentes qu' il faut réapprendre et même pour qq' un d' expérimenté en programmation c'est assez déstabilisant de passez du temps sur des choses triviales.

C' est en forgeant qu' on devient forgeront, n' est ce pas ? ;-)

Avec l' expérience je pense qu' on prend du recul sur le framework , ce qui permet en effet de mieux comprendre la théorie de symfony donc des différents choix qui s' offrent à nous lors de l' implémentation d' un nouveau module par exemple.

J' ai souvent entendu dire , on programme plus vite avec un framework de type MVC..

Certainement à long terme, mais pour les premiers projets, le cafeine et le courage sont vivement conseillés. :-)

Bonne journée.

[Michel Rotta]

Tous dépend d'où tu viens.

Si tu viens du PHP procédurale, tous dans un fichier, PHP mixé avec les HTML et, parfois, des inclusions de fichiers.

Alors, effectivement, le "choc" d'un framework en modèle objet avec l'application des couches MVC et l'utilisation d'interface doit faire un certain choc !

Après, il faut dans tous les cas, comprendre les bases d'utilisations du framework, surtout d'un framework du type de symfony qui est "borné" dans la mesure où, pour fonctionner, on est obliger de suivre un schéma imposé (zend par exemple est plus souple dans son utilisation). Et une fois cela compris, il reste à comprendre le fonctionnement interne, mais ceci n'est utile que si tu souhaites écrire des plugins.

[mantex]

Oui effectivement je suis à la base admin sys qui a besoin de plus en plus de développer des couches web (ihm) pour la couche présentation.

J' ai rencontré un peu les mêmes problématiques sous ROR, il y a quelques années pour les besoins d' un projet spécifique. La syntaxe est tellement implicite et déroutante au début pour effectuer des actions précises et non génériques.

Heureusement j' ai appris à programmer en C++ au tout début, donc le concept de POO ne m' est pas totalement indifférent, mais cela était resté pour moi de la théorie et des souvenirs scolaires très lointain.

Depuis php s' est imposé sur le web, puis les cms templatisables, modulables donc il est vrai que la reprise à la prog est un peu rude.

Mais c ' est toujours passionnant d' apprendre de nouvelles choses et de partager cela avec d' autres.

C' est comme cela qu' on avance je pense...n' est ce pas ?

En tout cas bravo michel pour ton aide, qui doit en dépanner plus d' un ici.