Personnellement je fais ma conception sur Workbench puis je repart « from scratch » pour faire mon (mes) fichier(s) yml. (Oui oui on peut en avoir plusieurs de yml :p).

Quand j’étais sur Propel J’avais perdu quelque cheveux quand j’avais essayé l’autre méthode (cad de générer le fichier SQL, l’insérer en base, et laisser faire symfony pour du reverse engineirng). Le souci du reverse c’est que ça produisait trop de code inutile (sur les foreign key par exemple) et au final repasser derrière pour arranger le model m’avait fait perdre pas mal de temps.

Hors ce soir j’ai trouvé, je ne sais comment, un plugin pour Workbench pour écrire le fichier yml directement à partir de celui ci, adieu les étapes « insertion bdd, reverse ». Et en plus sur les (mini) tests que j’ai fait tout à l’air propre, les conventions doctrines sont respectés, tout est bien indiqué. Il suffit de suivre la marche à suivre suivante : http://code.google.com/p/mysql-workbench-doctrine-plugin/wiki/WorkbenchPreparationForDoctrinePlugin

Bref, en un mot c’est bon plugin Workbench bien utile :p

Hein ? Mais à quoi ça sert ?

Ce que j’en retiens c’est que cela peut permettre d’automatiser certaines actions (répétitives) à l’enregistrement en base, et donc d’enrichir son modèle et deux coup de cuillère à pot.

Prenons un exemple, vous devez faire un site basé sur la créations de contenus par vos utilisateurs. Ils peuvent écrire des billets, commenter, s’envoyer des messages privés, gérer un annuaire .. bref un site où l’on doit quasiment tout relié à un utilisateur. Chaques tables auraient donc au moins un « user_id » comme clée étrangère ce qui implique dans vos actions d’associer l’utilisateur courant à l’objet pour le sauvegarder .. et ce pour chaque table … lourd non ?

Hé bien grâce aux behaviors vous pouvez sortir ce comportement générique dans des classes et avec seulement de la configuration au niveau de votre schéma, vous pouvez associer ce comportement à n’importe quel table. L’exemple que j’ai pris est tiré du behavior « Signable » du plugin sfDoctrineActAsSignablePlugin.

Configuration

1
2
3
4
5
6
7
8
9

Item:
  actAs:
    Signable:
  columns:
    id:
      type:             integer
      primary:          true
      autoincrement:    true
    champ1:             string(255

Comment ça marche ?

Donc si on résume, il faut dire à Doctrineque l’on va rajouter des colonnes .. et que l’on veut être prévénu lors de l’insertion en base pour associé nos actions. Donc avec seulement 2 classes, une de définition et une d’écoute, on peut s’en sortir et crée notre behavior.

Lors de la configuration, en rajoutant « actAs : Signable », Doctrine va chercher une classe de définition qui ira  étendre une classe Doctrine_Template. Par convention il ira chercher une classe nommé Doctrine_Template_Signable. Le rôle de cette classe est de déclarer ses colonnes et de rajouter une écoute, un listener, vers l’autre classe d’actions.

Pour mon exemple, je vais volontairement raccourcir les classes du sfDoctrineActAsSignablePlugin et prendre pour acquis que vos utilisateurs sont gérés via sfGuardDoctrinePlugin.

Doctrine_Template

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class Doctrine_Template_Signable extends Doctrine_Template {
 
  // Définitions des relations
  public function setUp() {
  // Bim rajoute une clée étrangère sur sfGuard
  $this->hasOne('sfGuardUser as Author', array(
            'local' => 'created_by',
            'foreign' => 'id'
            )
            );
  }
 
 public function setTableDefinition() {
 
  // Bim une colonne en plus
  $this->hasColumn('created_by', 'integer', 4, array(
          'type' => 'integer',
          'length' => '4',
     ));
 
  // Lien avec notre 2eme classe .. on passe le nom de la colonnette rajouté
  $this->addListener(new Doctrine_Template_Listener_Signable('created_by));
  }
}

Là pour l’exemple aucune configuration au niveau du schéma n’est possible mais c’est facile à rajouter via d’un tableau d’options et le constructeur suivant :

1
2
3

  public function __construct(array $options = array()) {
    $this->_options = Doctrine_Lib::arrayDeepMerge($this->_options, $options);
  }

Doctrine_Template_Listener

Nous avons vu que notre Template rajoute un listener vers notre 2e classe en lui passant la colonne à surveiller (dans la vrai vie, un tableau d’options ..). Le rôle de notre listener de pouvoir agir avant/après l’insertion/édition d’un objet .. facile :

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
27
28
29
30
31
32
33
34
35
36
37
38
39

class Doctrine_Template_Listener_Signable extends Doctrine_Record_Listener {
 
  protected $_colonette = "created_by";
 
  public function __construct($colonne) {
    $this->_colonette = $colonne;
  }
 
  public function preInsert(Doctrine_Event $event) {
      $createdName = $this->_colonette;
 
      // recupère l'objet appellant :
      $objet = $event->getInvoker();
 
      // Affectation de valeur
       $objet->$createdName = $this->getUserId();
  }
 
  public function getUserId() {
     // Echappe le mode cli
     if (0 != strncasecmp(PHP_SAPI, 'cli', 3)) {
       // L'user courant
       return sfContext::getInstance()->getUser()->getAttribute('user_id', null, 'sfGuardSecurityUser');
     } else {
      return null;
     }
  }
 
  public function preUpdate(Doctrine_Event $event) {
  }
 
  public function postUpdate(Doctrine_Event $event) {
  }
 
  public function postInsert(Doctrine_Event $event) {
  }
 
  // A tester : public function Delete(Doctrine_Event $event) ..
}

Vous n’avez plus qu’a rebuilder votre model et magie ça doit marcher !!

Vu que l’on a fait une relation de type One-to-many sur sfGuard vous pouvez accéder à l’utilisateur sfGuard via la propriété Author sur n’importr quel table marqué comme « Signable »

1

  echo $objet->Author->id;

Voilà .. simple au final non ? Ah vous de créez le votre, :p

Comme on dirait au boulot « Amaaziiiing !! »

Page 404 :

Pour la page 404 c’est dans le fichier settings de votre application
/apps/front/config/setting.yml

Il faut tout simplement rajouter ces deux directives

1
2
3

all:
  error_404_module: home
  error_404_action: error404

Du coup quand vous aurez une erreur 404 cela sera votre page qui sera affiché, vous pourrez donc dans votre action vous ajoutez une petite ligne pour vous envoyer un mail quand y a un souci. (Le plugin nahoMail est vraiment top d’ailleurs). Du monitoring pas cher quoi.

Page 500 :

Vous croyez qu’il aurait fallu mettre

1
2
3

all:   
   error_500_module: home 
   error_500_action: error500

Et bien ça ne marche pas du tout comme ça. Pour personnaliser cette page vous devez placer un fichier « error.html.php » dans le répertoire « apps/front/config/error » (crée le au besoin). Et c’est tout.

Mais du coup voilà, nous ne sommes pas dans une action .. donc cette page n’est pas inclu dans votre layout, on ne peut non plus utiliser les classes Symfony.. et oui la page d’erreur 500 est complétement statique. Adieu le monitoring pour cette page.

Si vous connaissez un moyen de customiser cette page et de pouvoir profiter du framework en même temps je suis preneur :p

Sur ceux, à bientôt pour de nouvelles astuces Symfony

Je préviens que ce blog risque de ne pas être mis à jour pendant encore un moment. J’emménage à Lyon, je change de job, et je n’aurais plus de mac pour développez sur iphone tout de suite. Donc pour les lecteurs « iphone » du blog désolé mais c’est chômage technique en vue.

C’est con, j’aurais bien aimer tester la réalité augmenté sur iphone grâce à http://code.google.com/p/iphonearkit. L’avez vous tester cette libraire vous ? Mais bon, je n’ai pas d’iphone 3GS non plus. D’ailleurs si vous avez un mac, un iphone 3GS que vous voulez me donner, y a pas de souci je prend :p

Petite annonce iphone : Je suis à la recherche de dev iphone sur Lyon, débutant ou confirmé. N’hesitez pas à vous signaler par mail, je ne mord pas.

Par contre, pour ceux qui viennent pour du PHP et pour Symfony vont être content. Mon nouveau job m’en fera faire 8h par jour, je parie que je vais découvrir pleins de trucs que je posterais sur ce blog. :p

Adieu objective-c, welcome PHP. (La tendance est de faire l’inverse, mais moi je ne suis pas comme les autres ;p)

Loin de moi l’idée de faire un comparatif, mais voilà mon opinion entre Zend et Symfony …mon coeur balance ^^

Merde, c’est un comparatif très objectif. Tans pis. Vous noterez que je préfère symfony (c’est mon 1er framework alors bon c’est normal ^^).

Mais comme dirais un Romain … « le framework dépend du projet, desfois c’est mieux sans » :)

Sur ceux, bonne journée

Je prend pour acquis que vous ayez lu / que vous connaissez la validatation de formulaire « classique » offert par sfForm. Tout est expliqué là et surtout là.

En fait le souci avec les validateurs symfony 1.1 est qu’ils ne possèdent pas la méthode isValid() contraitement aux validateurs symfony 1.0. Du coup, quand on fait de l’ajax, nous sommes obligés de passer d’un type de validateur à un autre.

Cette exemple illuste le fait avec le validateur sfValidatorEmail (sf 1.1) et sfEmailValidator (sf 1.0). L’idée est de définir les paramêtres du validateur (les messages d’erreurs dans notre cas) qu’à un seul endroid afin de respecter le concept Dry (Don’t Repeat Yourself).

Voilà les étapes nécessaires pour mettre en place une validation de formulaire classique et « Ajaxé » :

1. Vous créez vos widgets dans lib/form/MaClasseForm.class.php
   ^?View Code PHP

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

   class MaClasseForm extends BaseMaClassForm { public function configure() { $this->setWidgets(array( 'id' => new sfWidgetFormInputHidden(), 'FirstName' => new sfWidgetFormInput(), 'LastName' => new sfWidgetFormInput(), 'Email' => new sfWidgetFormInput(), 'password_repeat' => new sfWidgetFormInput(), 'password' => new sfWidgetFormInput() ));   // On peut modifier les labels si besoin est ... $this->widgetSchema->setLabels(array( 'FirstName' => 'Prenom', 'Email' => 'addresse Email ', 'LastName' => 'Nom', )); } }

2. Vous définissez vos validateurs dans lib/form/MaClasseForm.class.php à la suite de la méthode configure()
   ^?View Code PHP

   1 2 3 4 5 6 7 8 9 10 11 12 13

   $this->setValidators(array( 'id' => new sfValidatorPropelChoice(array('model' => 'Utilisateurs', 'column' => 'id', 'required' => false)), 'FirstName' => new sfValidatorString(array('max_length' => 20, 'required' => false)), 'LastName' => new sfValidatorString(array('max_length' => 20, 'required' => false)), 'password' => new sfValidatorString(array('max_length' => 40, 'required' => false)), 'password_repeat' => new sfValidatorString(array('max_length' => 40, 'required' => false)), 'Email' => new sfValidatorEmail(array('required' => true)), 'Birthday' => new sfValidatorDate(array('required' => false)), ));   // J'en profite pour definir un nom formater des champs pour avoir $_POST['utilisateurs['email']] etc $this->widgetSchema->setNameFormat('utilisateurs[%s]');

3. Normallement à ce stade vous pouvez utiliser la classe de formulaire dans votre fichier apps/MonApp/MonModule/actions/actions.class.php
   ^?View Code PHP

   1 2 3 4 5 6 7 8 9 10 11 12 13

   public function executeMonAction() {   $this->formInscription = new MaClasseForm(); if ($this->request->isMethod('post')) { // récupère les champs du formulaire sous forme de tableau. $array_champ = $this->getRequest()->getParameter("utilisateurs"); $this->formInscription->bind($array_champ); if ($this->formInscription->isValid()) { // Formulaire valide. } }

4. Voilà la validation « classique » et faite. Et l’ajax dans tout ça ? On y vient ^^ Alors au lieu d’afficher le formulaire de manière classique (via le template adéquate apps/MonApp/MonModule/templates/MonActionSuccess.php)
   ^?View Code PHP

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   // Au lieu de echo $form;   // On va rendre le template comme on le souhaite // Par souci de flemme je ne fait que le champ Email <table> <tr> <td><?php echo $form['Email ']->renderLabel() ?>:</td> <td><?php echo $form['Email '] ?></td> <td><span id="error_for_email "> <?php if ($form['Email ']->hasError()): ?> <ul class="error_list"> <?php foreach ($form['Email ']-<getError() as $error): ?> <li class="error_for"><?php echo $error ?></li> <?php endforeach; ?> </ul> <?php endif; ?> </span></td> </tr> </table>

5. Et maintenant on va jouer avec l’ajax pour vérifier ce champ email lors de la saisie.
   ^?View Code PHP

   1 2 3 4 5 6 7 8 9 10

   /************** Ajax Time :) *****************/ // Dans le template on met : <?php // Crée l'observateur pour le champ utilisateurs_email du formulaire. echo observe_field("utilisateurs_email",array( 'update' => "error_for_email", 'url' => "MonModule/VerifierEmail", 'with' => "'email='+ value", )); ?>

6. On rajoute l’action VerifierEmail() dans le fichier d’actions.
   ^?View 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 27 28 29 30 31 32 33 34 35 36 37 38 39 40

   public function executeVerifierEmail() { // Initialisation des variables internes $chaine_a_verifier = $this->getRequestParameter("email"); $array_erreur = array();   // Récupère le validateur d'email définit dans lib/form/MaClasseForm.class.php $form = new MaClasseForm(); $validateur_form = $form->getValidatorSchema(); $all_validateurs_field = $validateur_form->getFields(); $email = $all_validateurs_field["email"];   // Récupere le bon code d'erreur if($chaine_a_verifier == "") { $array_erreur = array('email_error' => $email->getMessage("required")); } else { $array_erreur = array('email_error' => $email->getMessage("invalid")); }   // Crée un validateur d'email hérité de Symfony 1.0 $validateur_email = new sfEmailValidator($this->getContext());   // Un peu de Dry (Don't Repeat Yourself) afin d'éviter d'avoir des messages d'erreurs définit à deux endroits différents. $validateur_email->initialize($this->getContext(), $array_erreur ); // Dispatcheur vers le bon templates if($validateur_email->execute($chaine_a_verifier,$message_retour)) { $message_a_afficher = $this->getPartial("ajax_error",array("message"=>$message_retour,"reussi"=>true)); } else { $message_a_afficher = $this->getPartial("ajax_error",array("message"=>$message_retour,"reussi"=>false)); }   return $this->renderText($message_a_afficher); }

7. Donc en fait on met à jour le « span » error_for_email avec le résultat de l’appel de la méthode VerifierEmail(). J’ai utilisé un template partial car le but est de le réutiliser pour tous les appels en Ajax. Celui ci n’est pas bien compliqué
   ^?View Code PHP

   1 2 3 4

   <ul> <li class="<?php if($reussi) echo "accept_for"; else echo "error_for"; ?>">&amp;nbsp;<?php echo $message; ?> </li> </ul>

8. Et voilà, le formulaire fonctionne classiquement et dispose de vérifications en Ajax aussi.

Nous venons de voir le validateur d’Email, mais tous fonctionnent sur le même principe. Voici la méthode pour utiliser le validateur de Sting qui diffère un peu.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

   public function executeVerifierPseudo()
   {
     // Initialisation des variables internes
    $chaine_a_verifier = trim($this->getRequestParameter("pseudo"));
 
    // Récupère le validateur de pseudo
    $form = new MaClasseForm();
    $validateur_form = $form->getValidatorSchema();
    $all_validateurs_field = $validateur_form->getFields();
    $validateurs = $all_validateurs_field["FirstName"];
    $pseudo = $validateurs->getValidators();
    $pseudo = $pseudo[0];
 
    // Crée un validateur de String sf1.0
    $validateur_pseudo = new sfStringValidator($this->getContext());
    $validateur_pseudo->initialize($this->getContext(), array(
    'min' => $pseudo->getOption("min_length"),
    'min_error' => $pseudo->getMessage("min_length"),
    'max' =>$pseudo->getOption("max_length"),
    'max_error' => $pseudo->getMessage("max_length"),
    'required' => $pseudo->getMessage("required"),
    ));
    // Dispatcheur vers le bon templates
    if($validateur_pseudo->execute($chaine_a_verifier,$message_retour) && $chaine_a_verifier != "")
    {
       $message_a_afficher = $this->getPartial("ajax_error",array("message"=>$message_retour,"reussi"=>$bool));
    }
    else
    {
     if($chaine_a_verifier == "") $test = $pseudo->getMessage("required");
 
     // Remplace les jokers des messages d'erreurs.
     $min = $pseudo->getOption("min_length");
     $max = $pseudo->getOption("max_length");
     $message_retour=    preg_replace("#%value%#",$chaine_a_verifier,$message_retour);
     $message_retour=    preg_replace("#%min_length%#",$min,$message_retour);
     $message_retour=    preg_replace("#%max_length%#",$max,$message_retour);
     $message_a_afficher = $this->getPartial("ajax_error",array("message"=>$message_retour,"reussi"=>false));
   }
 
   return $this->renderText($message_a_afficher);
}

Et voilà c’est fini :)