[phpsymfony.com] - Blog par un programmeur pour les programmeurs

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, avril 7 2010

[symfony] Sécurité

J'espère que vous avez bien configuré votre serveur web pour ne pas que les fichiers de configuration soient vus par le robot Google.

Ces sites là ne l'ont pas fait ... et ils s'exposent à de graves problèmes...


lundi, mars 1 2010

[symfony] Surcharger le message d'erreur d'unicité de Doctrine

Lorsque l'on définit une contrainte d'unicité (unique: true dans le schema.yml) sur un champ, Doctrine va automatiquement afficher un message d'erreur : La colonne "column" existe déjà. Ce message n'est pas très joli à voir puisque la colonne n'est pas traduite. Pour le personnaliser, il faut le surcharger.

 $validatorLabel      = new sfValidatorDoctrineUnique(array('model' => 'MoperMissionPlace', 'column' => ('label')));
   $validatorLabel->setMessage('invalid', 'An object with the same value already exists');
   $this->validatorSchema->setPostValidator(
     new sfValidatorAnd(array(
       $validatorLabel
   ))
   );

mercredi, février 10 2010

[symfony] Charger des helpers dans le contrôleur ou le modèle

Pour charger un helper dans un template, il suffit d'utiliser la fonction :

use_helper('helperName');

Mais qu'en est-il dans le contrôleur ou le modèle ?

On peut utiliser en sf 1.0 et 1.1 :

sfLoader::loadHelpers('helperName')


Mais cette méthode est obsolète dans les versions >= 1.2

Il faut utiliser à la place :


sfContext::getInstance()->getConfiguration()->loadHelpers('helperName');

Si vous êtes dans une task :

$configuration = ProjectConfiguration::getApplicationConfiguration('backend', 'dev', true);
$context       = sfContext::createInstance($configuration);
$configuration->loadHelpers('HelperName');

mardi, janvier 19 2010

[symfony] Eviter la mise à jour de updated_at

Au cours d'un projet, j'ai eu à implémenter un système de verrouillage sur les objets d'une table. Ce verrouillage était réalisé avec la modification d'une colonne (locked_until) contenant un timestamp.

Le problème était que lorsque je mettais à jour cette colonne, le updated_at de mon objet était lui aussi mis à jour, ce qui est tout à fait normal.

J'ai donc essayé de trouver comment contourner la mise à jour du champ et j'ai finalement trouver ça :

  public function updateLock($userId)
  {
    $updatedAt = $this->getUpdatedAt();
    $this->setLockedUntil(time() + sfConfig::get('app_lock_delay'

));
    $this->setLockedBy($userId);
    $this->save();
    $this->setUpdatedAt($updatedAt);
    $this->save();
  }


On sauvegarde l'ancienne valeur de l'updated_at, puis on effectue les modifications sur l'objet et on sauvegarde. Ensuite (et voila l'astuce) il suffit de faire un appel à setUpdatedAt() et de sauvegarder à nouveau l'objet. Ainsi, la valeur n'aura pas changé !

lundi, décembre 21 2009

Symfony - Valeurs par défaut dans un formulaire

Lorsque j'ai débuté avec Symfony 1.2, j'ai été bluffé par le framework de formulaires. Ayant eu une expérience principalement sur symfony 1.0, il a donc fallu une petite période d'adaptation...
En tout cas, une des première problématique que j'ai rencontré était de mettre des valeurs par défaut dans une classe formulaire.

Pour ce faire, il faut utiliser la méthode setDefault(s).

$this->setDefaults(array(
  'colonne1' => 'valeur1',
  //...
);



Dans le cas d'un formulaire objet, on peut remplir le formulaire en fonction des données existantes en base.
On surcharge la méthode updateDefaultsFromObject() de la classe formulaire.

Utiliser :

$this->object->setXXX() ; //ou XXX est une propriété de l'objet



L’utilisation de $this->isNew() est très pratique, on peut ainsi savoir s'il s'agit d'une création ou d'une édition.

Attention : ne pas oublier l’appel au parent : parent::updateDefaultsFromObject()

Je posterai un exemple pour une meilleure compréhension.