By Olivier Balais
Aujourd’hui chez PMSIpilot, je suis tombé sur le problème suivant : après avoir passé une valeur par défaut à un des widgets de mon formulaire, je ne parvenais pas à la récupérer dans mon action ni dans mon template.
L’appel à la méthode getDefault du sfForm me renvoyait systématiquement null,.
Le code en question :
// Dans le code de mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(array('default' => 'my_value')),
));
// Dans le code de mon action :
if ($my_form->getDefault('my_field') == 'some_value')
{
...
}
Dans ce cas, la méthode getDefault() appelée sur mon formulaire me renvoie null alors que j’ai explicitement donné une valeur par défaut à mon widget. Pourtant, en lisant la doc de symfony sur le sujet je retiens ceci :
The setDefault(), getDefault(), setDefaults(), and getDefaults() methods manages the default values for the embedded widgets. They are proxy methods for the getDefault() and setDefault() widget methods.
Les méthodes setDefault() et getDefault() au niveau de la classe sfForm sont censées êtres des raccourcis pour les méthodes setDefault() et getDefault() de la classe sfWidgetForm().
En fait il s’avère que ce n’est absolument pas le cas et que la méthode getDefault() du formulaire ne fait jamais appel à la méthode getDefault() du widget associé.
L’appel à $my_form->getDefault(‘my_field’) n’est donc pas équivalent à $my_form['my_field']->getWidget()->getDefault().
Par conséquent, il est important de bien comprendre quelle méthode appeler et dans quel cas.
A savoir, $my_form->getDefault(‘my_field’) quand le setDefault a été utilisé au niveau du formulaire. Exemple :
// Valeurs passées dans mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(),
));
$this->setDefault('my_field', 'my_value');
// Ou alors valeurs passées dans mon action :
$my_form = new myFormClass(array(
...
'my_field' => 'my_value',
));
Et, $my_form['my_field']->getWidget()->getDefault() quand le setDefault() a été utilisé au niveau du widget. Exemple :
// Dans le code de mon formulaire :
$this->setWidgets(array(
...
'my_field' => new sfMyWidget(array('default' => 'my_value')),
));
Voilà, désormais vous êtes prévenus…
By adrien.gallou
Après avoir écrit quelques tests unitaires, on peut se demander si les tests écrits couvrent
une partie assez importante du code de la classe testée, quelles peuvent être les classes restantes à tester ou tout simplement avoir une idée de l’étendue du projet couverte par des tests unitaires.
Pour cela nous utiliseront le plugin Hudson Emma pour l’affichage dans Hudson, ainsi que le plugin symfony agEmmaCoverageReport pour générer le fichier xml au format emma.
Le format « emma » est à la basée utilisé en java, plus d’infos sur le site du projet.
Utilisation de la tache de génération du rapport xml
L’extension xdebug doit être installée (mais pas forcément activée).
Les fichiers testés sont trouvés en utilisant l’autoload, les fichiers de tests doivent être nommés de la façon suivante : nomDeLaClasseTesteeTest.php, par exemple le classe « qualifactCellFormatterEuro » aura pour fichier de test « qualifactCellFormatterEuroTest.php ».
Voyons tout d’abord comment fonctionne la génération du fichier xml de rapport :
Si xdebug est activé par défaut :
./symfony ecr:report --xml=cheminOuSauverLeXml.xml
Mais sur le serveur d’intégration cela n’est probablement pas le cas, et il serait
gênant d’avoir à l’activer pour les autres tests alors que qu’il est seulement utilisé pour le coverage.
Pour cela on peut indiquer à la tache le chemin ou se situe l’extension xdebug (par exemple sur une Mandriva il se situe ici : « /usr/lib/php/extensions/xdebug.so »). La tâche sera alors appelée de cette façon.
./symfony ecr:report --xml=cheminOuSauverLeXml.xml --xdebug-extension-path=/usr/lib/php/extensions/xdebug.so
Intégration dans Hudson CI
Création et configuration du job
- Dans le menu de gauche : « Nouvelle Tache »
- Cliquez sur « Construire un projet free-style »
- Donnez un nom au job
- Entrez alors l’url du dépôt
- Après checkout nous voulons lancer les tests unitaires ainsi que la tache créant
le rapport de coverage, nous allons donc ajouter une étape au build. Celle ci sera de
type « Executer un script shell »
- Dans la liste des commandes nous allons donc lancer les tests et le coverage de cette façon :
$WORKSPACE/symfony test:unit --xml=log/unit.xml
$WORKSPACE/symfony ecr:report --xml=log/coverage.xml
- Pour les résultats des tests unitaires, cochons la case « Publier le rapport des résultats de tests JUnit » puis dans « XML des rapports de test » nous indiquons ou chercher le fichier XML en saisissant : « log/unit.xml »
- Pour le code coverage, cochons la case « Record Emma coverage report » puis dans « Folders or files containing Emma XML reports » nous indiquons où chercher le fichier XML en saisissant : « log/coverage.xml »
- Il faudra ensuite exécuter le job
Affichage du rapport de code coverage
Après lancement du job les résultats du code coverage apparaissent dans la section « Coverage Trend ».
Pour un détail du coverage il faut cliquer sur le graphique.
La couverture du code par les tests unitaire est alors présentée par package ainsi que par classe, méthode, bloc et ligne.
Les blocs sont tous à 0 car c’est une notion seulement utilisée en java. Une méthode ou une classe est couverte si toutes les lignes qui la contiennent sont couvertes. Ainsi certaines classes, ne contenant aucune ligne de code, ayant juste leur déclaration, seront indiquées comme couvertes à 100%.
By admin
PMSIpilot conçoit et réalise une suite informatique dédiée à l’amélioration de la gouvernance des hopitaux publics. Le périmètre fonctionnel peut s’apparenter à un outil décisionnel ou de Business Intelligence concernant l’activité, d’un point de vue financier et médical, de l’hôpital.
Il y a deux ans, le projet a connu un virage technologique important. D’une technologie obsolète et d’un conception un peu hasardeuse (PHP4, framesets, …), un projet de refonte vers symfony 1.2 a été lancé. Cette refonte a durée un peu plus de 20 mois / homme et a abouti à un seul projet symfony contenant plusieurs applications. PMSIpilot a, dès le début, pris le parti d’utiliser les conventions de symfony et le paradigme MVC.
En chiffres, aujourd’hui
- 12 développeurs (en constante augmentation !),
- 410 déploiements,
- environ 50 000 utilisateurs répartis sur toutes ces instances,
- environ 220 000 lignes de code PHP écrites et maintenues,
- la prochaine release importante intégrera symfony 1.4.
Comment symfony nous aide
La documentation et la communauté
La documentation de symfony nous permet d’intégrer rapidement une nouvelle recrue. Le fait de trouver de nombreuses contributions au framework (sur symfony-project.org ou bien ailleurs) est très facilitant également. Nous utilisons de nombreux plugins comme :
- sfPropelPlugin
- dwJpGraphPlugin
- sfDB4toPropelPlugin
- sfPropelSqlDiffPlugin
- sfJqueryReloadedPlugin
- sfValidatorHtmlPlugin
- sfJobQueuePlugin
- sfFormExtraPlugin
- …
Parfois tels quels, parfois un peu modifiés pour nos besoins.
Le développement
- le framework nous donne une bonne structure de base pour l’organisation du code source ainsi que des normes de codage, sur une équipe aussi importante cela permet de gagner du temps,
- mis à part i18n et l’admin générator, on utilise la quasi totalité de la stack de symfony : MVC, le cache, les filtres, les évènements, le système de gestion des utilisateur, l’ORM, les tasks, …
- symfony est suffisament flexible pour que nous puissions facilement l’adapter à nos besoins parfois bien spécifiques ; aujourd’hui nous avons étendu : sessionStorage, viewCacheManager, ApplicationConfiguration et ProjectConfiguration, sfAction, sfComponent, sfView, frontWebController, plein de choses autour de propel …
- nous ajoutons des fonctionnalités tous les jours, et une grande réactivité nous est demandé pour suivre l’évolution de la réglementation ; le framework de test nous permet de garantir aucune régression et de livrer des correctifs très rapidement si nécessaire (voir plus bas),
- le système de task, de gestions des fixtures, d’environnement de développement permet de proposer des méthodes faciles d’accès au développeur permettant d’instancier un environnement de dev complet et identique à ses collègues.
L’intégration continue
Dès la refonte du projet, sécuriser ces mises à jours a été une priorité. C’est pourquoi nous avons investi dans le développements d’un grand nombre de tests fonctionnels et leur suivi au sein d’une instance Hudson.
Les tests fonctionnels chez PMSIpilot vérifient des cas d’utilisation standards mais sont surtout utilisés pour valider la totalité des données chiffrées présentées. A ce titre les quelques 250 000 tests fonctionnels sont majoritairement générés (on ne teste pas vraiment « les tests » mais « les étalons des tests »).
La création de nouvelles classes a entrainé l’écriture d’une centaine de tests unitaires (avec des efforts pour optimiser la couverture du code).
Enfin, nous avons commencé l’écriture de tests d’interface avec Selenium (une dizaine aujourd’hui) afin de gérer plus facilement les différents navigateurs (parfois un peu datés) de nos clients. (oui, ça n’a rien à voir avec symfony …)
Pour boucler la boucle on a, en projet, l’intégration automatique de tests de montée en charge. (un outil à suggérer ?)
Comment nous tentons d’aider symfony
Dans la mesure du possible, nous tentons de faire bénéficier la communauté symfony de nos travaux, en remontant des bugs et en proposant des plugins . Nous essayons également de partager les slides des réunions techniques organisées au sein de l’équipe afin de diffuser les compétences au sein des équipes.
Chez PMSIpilot, on aime symfony. Si c’est votre cas aussi, n’hésitez pas à proposer votre candidature au service technique.
By admin
So far, voici la liste de nos très modestes contribution à Symfony, le framework PHP utilisé chez nous :
tickets :
- #1776 (fixed) [PATCH] checkbox arrays not checked with fillin enabled
- #2916 (wontfix) Bug in Spyc : losing data with successive load/dump
- #3792 (fixed) i18n XLIFF do not handle entities correctly
- #4306 (wontfix) sfDebugConnection does not handle correctly logging of nested transactions
- #4620 (fixed) [PATCH] – PHP5NestedSetBuilder generate a require to lib/model/om/Basesometing
- #5374 (fixed) Changeset [14122] breaks config parsing
- #5402 (fixed) sf doc refer to the getDispatcher() method but it doesnt exist
- #5964 (fixed) Notice sur sfTestBrowser
- #7446 (fixed) sfOutputEscaper::unescape($vars) appelé systématiquement dans _call_component
- #6639 (fixed) Option passed to a widget schema do not get passed through to an sfWidgetFormChoice’s renderer
- #8365 (opened) sfFinder not_name does not works if results intersects due to #6589
- #8384 (opened) sfPropelPluginConfiguration::filterAutoloadConfig should exclude vendor dir just like in the plugin autoload file
- #8402 (opened) sfPropelBaseTask should add propel include path by using sf_propel_runtime_path
- #8457 (fixed) sort the parameters in order to compute the cache key the same way when parameters are submited in different order
plugins :
- omCredentialsMapPlugin : This plugin allows you to check all the credentials in your project and detect action not or badly securised
- omCrossAppUrlPlugin : Simple helper to get cross app urls
- elXHProfPlugin : Integration of XHProf profiler (simple API to profile + web debug toolbar integration)
By Eric Lemoine
Introduction
Il arrive souvent lors d’un développement informatique que l’on soit confronté à un problème de performances.
On essaie souvent d’optimiser des bouts de code que l’on croit être la cause des ralentissements mais sur des projets assez complexes il arrive qu’on ne regarde pas forcément au bon endroit.
Les étapes à suivre pour résoudre des problèmes de performances sont donc les suivantes :
- Mesurer : il est indispensable de connaître les performances actuelles de l’application/bout de code qui sous-performe.
- Optimiser (ou en tout cas essayer) : cela est lié à votre code, je vous laisse faire cette partie :)
- Comparer : est-ce que l’optimisation effectuée est vraiment efficace ? Tant qu’on n’est pas satisfait on revient à l’étape 2.
Je vais aborder dans cet article des solutions disponibles dans l’univers PHP pour permettre de travailler sur les étapes 1 et 3.
Read more »
