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

Pourquoi ? parce que.

Le sujet de l’application était d’afficher des images en fonction d’une ville – en vue de faire du data binding sur un XML « statique » de villes – et de récupérer des images issues d’un XML dynamique via l’objet HTTPService.

Alors quitte à faire du dynamique, autant interroger directement un web service existant en vue de récupérer pleins d’images sans se prendre la tête. Et là j’ai pensé à FlickR et sa monstrueuse API. Après 5mn montre en main j’ai eu ma clé pour accèder à l’API et 4mn après je découvrait phpFlickR.

Upload de la librairie et voici mon bout de script qui me renvoit suivant deux paramètres en $_GET un joli XML près à être utilisé en Flex.

• $_GET['town'] est le terme rechercher dans l’api FlickR sur les tags et le text qui commente une photo.
• $_GET['max'] est le nombre de photos qu’il faudra retourner.

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

require_once("phpFlickr.php");
$flickR = new phpFlickr("ta_cle_de_connection_flickR");
 
// 10 résultat par défaut ..
if(isset($_GET['max']))
$max = $_GET['max'];
else $max=10;
 
$search = array("tags"=>$_GET['town'],'per_page'=>$max, "tag_mode"=>"any",'text' => $_GET['town']);
$tab = $flickR->photos_search($search);
 
// On renvoit un XML à Flex
header("content-type: application/xml");
 
// La balise qui va bien
echo "<?xml version="1.0" encoding="utf-8" ?>";
 
for ($i = 0; $i != $max; $i++)
{
        // on s'assure d'avoir des photos valides
	if($tab['photo'][$i]['id'] != "")
	{
	// Simple de créer des urls FlickR non ?
	$url = $flickR->buildPhotoURL($tab['photo'][$i],"thumbnail");
	$link = $flickR->buildPhotoURL($tab['photo'][$i],"medium");
 
	echo "<image><url>".$url."</url><urlLarge>".$link."</urlLarge></image>";
	}
}

La partie Flex est tout aussi simple, voici la partie essentielle qui nous intéresse :

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
43
44
45
46

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="searchPhoto('france',20)">
 
<mx:Script>
<![CDATA[
import mx.rpc.http.HTTPService;
import mx.rpc.events.ResultEvent;
import mx.collections.ArrayCollection;
 
[Bindable]
private var servicePhoto:ArrayCollection = new ArrayCollection(); 
 
 
private function searchPhoto(search:String,max:int):void
{
	var modService:HTTPService = new HTTPService();
	modService.method = "get";
	modService.url = "http://oni-ecchi.info/labo/FlexPhotos/service.php";
 
	var parameters:Object = new Object();
	parameters.town = search;
	parameters.max = max;
	modService.request = parameters;                
	modService.send();
	modService.addEventListener(ResultEvent.RESULT,onDataCharged);                
}
 
private function onDataCharged(e:ResultEvent):void
{
	servicePhoto = new ArrayCollection();
	servicePhoto = e.result.root.image as ArrayCollection;		
	vignettes.dataProvider = e.result.root.image as ArrayCollection;
}
 
]]>
</mx:Script>
<mx:TileList id="vignettes" dataProvider="{servicePhoto}" width="481" height="279" columnWidth="110" rowHeight="110" columnCount="4" horizontalCenter="0" paddingRight="5" verticalCenter="0">
    <mx:itemRenderer>
   		<mx:Component>
   			<mx:Image  source="{data.url}" verticalAlign="middle" horizontalAlign="center" />
   		</mx:Component>
    </mx:itemRenderer>       
</mx:TileList>
 
 
</mx:Application>

Ce n’est qu’un exemple très simple. Dans le fichier source qui va suivre, j’ai un peu plus travaillé la chose en utilisant un composant de chargement d’image sympathique, un spinner de chargement 2.0 et enfin la gestion des states (très simple).

• Mon Projet Flex (zip)
  
• Le site d’exemple

Voilà, c’est tout pour aujourd’hui

Ca a l’air génial :) Dommage que ça soit seulement pour mac pour l’instant, mais c’est très prometteurs ! Apres un tour sur Symfony, sur Zend, faudrait que j’aille voir CakePHP donc :)

Je n’invente rien, j’ai trouvé la manip sur http://www.ericmery.fr/blog/zend_db-sql-server-procedure-stockee.

1
2
3
4
5
6
7
8
9
10

$registry = Zend_Registry::getInstance();
$config = $registry->get("config");
 
$db = Zend_Db::factory($config->db);
 
$stmt = $db->prepare("call import(?,?,?);");
$stmt->bindParam(1, $param1, PDO::PARAM_STR,1000);
$stmt->;bindParam(2, $param2, PDO::PARAM_STR, 255);
$stmt->bindParam(3, $param3, PDO::PARAM_STR, 255);
$res = $stmt->execute();

Magie, c’est la même chose. On remercie PDO et son abstracteur de base de donnée utilisé !

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

Mais grâce à http://new.imified.com, ce souci n’en est plus un ! Ce service web permet de connecter un bot à MSN, IRC, Gtalk etc et ce bot demandera à votre page PHP ce qu’il doit faire.

Au final nous n’avons plus qu’a se consacrer sur les réponses et les traitements à faire en fonction du dialogue de l’utilisateur (donnée récupérer sous forme de $_GET). Fini le parsage du stream pour détecter la bonne ligne ^^

Je vous avouerais, j’ai pas encore tester. Mais je compte le faire un de ces quatres :) Je pense que c’est LA solution pour créer rapidement un compagnon virtuel … Imaginer un bot de ce style qui pilote votre twitter, facebook etc. Vous lui parlez, il s’occupe du reste :)

Vu sur le channel #symfony-fr (irc.freenode.com) grâce à [MA]Pascal.
Il a crée un bot qui relaie ce que vous lui dites sur un site donné. (Système de prise de notes rapide)
Ajouter paste@bot.im à votre compte Gtalk et parler lui. Enfin, cela reste surtout un bot de test, réalisé avec Symfony 1.2 et Doctrine (un ORM comme propel)

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 :)