Tag - symfony
mercredi, avril 7 2010
[symfony] Sécurité
Par Guillaume Bretou le mercredi, avril 7 2010, 23:24
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
Par Guillaume Bretou le lundi, mars 1 2010, 23:46
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
Par Guillaume Bretou le mercredi, février 10 2010, 09:22 - Symfony
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
Par Guillaume Bretou le mardi, janvier 19 2010, 09:32 - Symfony
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($
$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
Par Guillaume Bretou le lundi, décembre 21 2009, 22:41 - Symfony
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.


