ProxyEPN

A lire quelques sujets de forum, il apparait que les Behaviors de Symfony (ceux gérés dynamiquement au travers des "hooks" et des "mixins") sont mal supportés par les tâches.

Vu la simplicité du plugin utilisé ici, le mieux serait sans doute de s'en passer pour le remplacer par le nouveau type de Behaviors que permet directement Propel (au moins depuis la version 1.4).

En attendant, concernant la version 2.0, le contournement du problème passe par la désactivation du behavior sfPropelActAsSignable dans la classe sfGuardUserProfile, le temps de créer le compte admin avec la tâche 'guard:create-user' :

Dans /lib/model/sfGuardUserProfile.php (dernière ligne) :
#sfPropelBehavior::add('sfGuardUserProfile', array('sfPropelActAsSignableBehavior' => array()));

Voir [[/boards/1/topics/137?r=147#message-147]]

Modifications publiées sur le svn (r483) :

Un nouveau Behavior Propel : MyPropelBehaviorSignable¶

Désormais le plugin Symfony sfPropelActAsSignableBehavior n'est plus utilisé, il disparait du projet !

Pour le remplacer, c'est cette fois un behavior Propel et non Symfony qui est mis en place. C'est donc au moment de la génération des classes par Propel que les bouts de code sont écrits directement dans les classes de base. Il n'y a plus besoin des hooks avec les déclarations dynamiques des mixins de Symfony. L'usage du behaviors se déclare désormais dans le schéma xml de la BdD utilisé par Propel.

Par rapport à son prédescesseur, les fonctionnalités sont similaires :

• Enregistrements automatiques de l'utilisateur avant la création, édition ou suppression d'un objet.
• Les noms des colonnes à utiliser sont paramétrables (par défaut : created_by, updated_by, deleted_by).
• Si une colonne n'existe pas dans le schéma de la BdD, alors l'action n'est pas ajoutée dans la classe de base.
• L'utilisateur est déterminé à partir du contexte Symfony
• La valeur enregistrée dans les champs est récupérée en fonction de leur type (INTEGER: getId() ou STRING: __toString()).
• Il est aussi possible de spécifier une méthode quelconque en paramètre pour récupérer la valeur à enregistrer.

De plus, des méthodes sont ajoutées aux objets pour récupérer le nom des utilisateurs plutôt que la valeur enregistrée, qui généralement correspond simplement à un identifiant. Ces méthodes effectuent une recherche sur la classe Peer des utilisateurs en prenant la valeur comme clé, pouvant ensuite retourner son nom.
Le nom de la classe des objets 'user' ainsi que la méthode pour obtenir le nom sont également paramétrables, par défaut sont utilisés respectivement sfGuardUser et __toString().

Liste des noms des paramètres avec leurs valeurs par défaut :¶

    protected $parameters = array(
        'create_column' => 'created_by',
        'update_column' => 'updated_by',
        'delete_column' => 'deleted_by',
        'user_method'   => TRUE, // default : 'getId' or '__toString'
        'user_class'    => 'sfGuardUser',
        'user_getname'  => '__toString',
    );

Exemple d'utilisation :¶

  <table name="room" idMethod="native">
    <column name="id" type="INTEGER" required="true" autoIncrement="true" primaryKey="true" />
    ...
    <column name="created_by" type="INTEGER" />
    <column name="updated_by" type="INTEGER" />
    <behavior name="signable"><parameter name="user_getname" value="getName" /></behavior>
  </table>

Le plugin sfPropelActAsSignableBehavior était le seul dans le projet à faire encore appel à l'ancien système des mixins de Symfony.

Maintenant qu'il s'est fait évincer, plus rien ne pourra perturber l'exécution des tasks de Symfony à ce niveau !

Le bug à l'origine de ce ticket est donc résolu.