Posted by: aimxhaisse on: February 2, 2009
Une etape importante dans la realisation de notre application est la synchronisation avec differents intranets existants: cela permet en autre de faire en sorte qu’une modification sur un intranet local (basiquement un changement de numero de telephone) se repercute sur notre application, et vice et versa. Sur certains intranets locaux, un logiciel interne indique le status d’un utilisateur, c’est egalement tres plaisant de voir ce status se mettre a jour sur notre application.
Pour cela, nous avons mis en place une API permettant d’effectuer les modifications sur notre application. Cette API prend la forme d’une application Symfony recevant du XML via des requetes GET/POST (a la maniere d’un systeme REST, mais tres allege et adapte a notre application), et en fonction de ce dernier, met a jour notre base de donnees.
Nous avons fait une petite librairie PHP permettant de faciliter les echanges en generant le XML et en offrant une abstraction aux requetes CURL. Ainsi, avec un petit CRON present sur chaque intranet local, on peut facilement remettre a jour les donnees de notre application, un petit screen pour illustrer cela :

Posted by: aimxhaisse on: December 9, 2008
Lorsque l’on doit realiser des requetes complexes avec Propel, on a souvent tendance a se renvoyer la balle
$criteria = new Criteria();
$criteria->addDescendingOrderByColumn( ProjectParameterPeer::CREATED_AT);
$criteria->setDistinct();
$criteria->add(ProjectParameterPeer::TITLE, “%”.$str.”%”, Criteria::LIKE);
if ($user->isAdmin())
return ProjectParameterPeer::doSelect($criteria);
$criterion1 = $criteria->getNewCriterion(ProjectUserPeer::USER_IDENTITY_ID, $user->getProfile()->getId());
$criterion2 = $criteria->getNewCriterion(ProjectUserPeer::USER_LEVEL, 0, Criteria::GREATER_THAN);
$criterion3 = $criteria->getNewCriterion(ProjectParameterPeer::ID, ProjectParameterPeer::ID .’=’. ProjectUserPeer::PROJECT_PARAMETER_ID, Criteria::CUSTOM);
$criterion4 = $criteria-> getNewCriterion(ProjectParameterPeer::IS_PUBLIC, true);
$criteria->add($criterion1->addAnd($criterion2)-> addAnd($criterion3)->addOr($criterion4));
$criteria->setLimit($limit);return ProjectParameterPeer::doSelect($criteria);
Bon par contre je n’aimerai pas avoir a la refaire celle la
PS: En fait propel c’est SUPER naze
Posted by: Gaspard on: November 24, 2008
Posted by: aimxhaisse on: November 21, 2008
Une petite fonctionnalite sympathique avec eclipse (qui n’est apparement pas activee par default), est la recherche automatique de mots clefs tels que TODO, FIXME, … dans le code. Un petit onglet permet alors de gerer la liste des taches a effectuer, avec un ordre de priorite selon son type.
Pour l’activer : clic droit sur le projet > properties > Task Tags > Enable searching for task tags
Plutot pratique, sauf dans notre cas ou ca devient vite le bordel car nous developpons une gestion de TODOs (on a donc plein de references a todo un peu partout dans le code
, qui viennent s’aglutiner dans notre petit onglet, sniff).
Posted by: Gaspard on: November 19, 2008
La version 1.1.5 de symfony vient d’être publiée en version stable, du coups, ô bonheur nous n’aurons plus de bugs d’encodage en surfant sur une appli via un proxy (ticket #4688).
Mettre à jour ? rien de plus simple :
pear upgrade symfony/symfony-1.1.5
Posted by: aimxhaisse on: November 17, 2008
Une chose que l’on fait tres regulierement lorsque l’on met en place des evenements AJAX, c’est le rebind. Qu’est-ce que c’est ca ? Prenons un exemple : un ajout de commentaire en AJAX.
Voici ce qui se passe lorsque l’on charge une premiere fois la page:
Voici un bout de code HTML representant les commentaires (etape 1):
<div class=”comment”>Super un commentaire !</div>
<div class=”comment”>Super un deuxieme commentaire !</div>
Et l’action javascript associee aux commentaires (etape 2):
$(“.comment”).click(function () { alert(“Hi there!”); });
C’est assez simple, une alerte apparait lorsque l’on click sur le commentaire.
Maintenant, si on ajoute un nouveau commentaire en AJAX, le DOM devient :
<div class=”comment”>Super un commentaire !</div>
<div class=”comment”>Super un deuxieme commentaire !</div>
<div class=”comment”>Groooom !</div>
Probleme, lorsque je click sur le commentaire “Grooom”, l’alerte n’apparait pas, normal ! Cet element du DOM n’a pas ete bind.
Soit l’on effectue un bind unique (ca demande une refactorisation totale du code) sur le dernier element, soit l’ont debind tout et l’on rebind tout. Pourquoi tout debinder? Car sinon, certains elements seraient bind 2 fois, ce qui voudrait dire que l’on aurait 2 alertes par click, ce n’est pas ce que l’on veut. J’ai eu pas mal de problemes a effectuer des bind uniques, et je me suis souvent embrouille en refactorisant du code pour pallier ce probleme.
J’ai donc souvent (si ce n’est toujours) tendance a debind tout, puis a rebinder, comme ceci
$(“.comment”).unbind();
$(“.comment”).click(function () { alert(“Hi there!”); });
Si l’on a 99 commentaires, cela veut dire que jQuery va debind chacun des commentaires, puis les rebinder 1 par 1 ? Ca fait pret de 200 operations, ca va prendre du temps, c’est long, ca serait plus efficace de ne rebinder que le dernier non?
Et bien en fait, on peut pallier ce probleme via une petite astuce: rajouter une classe binded a tous les elements que l’on a bind, et ne selectionner que ceux qui n’ont pas cette classe, ainsi le code devient:
$(“.comment:not(.binded)”).each(function() {
$(this).addClass(“binded”);
$(this).onclick(function () {alert(“Hi there!”);});
});
C’est certes un peu plus couteux en calculs qu’un bind unique, mais je trouve cela nettement plus lisible au niveau du code, et facile a faire evoluer.
Posted by: Gaspard on: November 13, 2008
Posted by: aimxhaisse on: November 12, 2008
Nous développons une application qui sera utilisée en interne par des utilisateurs qui seront sur des PC fixes, identifiés par une adresse IP, et nous voulons mettre en place un système d’authentification automatique, c’est a dire faire en sorte que lorsque l’utilisateur se connecte à l’application, ce dernier n’ait pas besoin de s’identifier.
Notre application sera située en dehors du réseau sur un serveur internet, et les utilisateurs accèderont à l’application via un proxy. C’est assez problématique dans la mesure où notre application sera incapable de déterminer quel utilisateur tente de se connecter une fois le proxy traversé.
Après avoir reflechi pendant un petit moment, nous avons décidé d’opter pour la solution suivante :
De plus, cela nous permet de nous familiariser un peu avec XMLRPC (qui nous servira pour synchroniser nos bases avec celles des différentes applications existantes).
Pour ce qui est des échanges XMLRPC, nous utilisons la librairie php-xmlrpc, qui permet une implémentation assez aisée et sécurisée des échanges (via SSL).
Posted by: Gaspard on: November 6, 2008
Lors de la mise en production ou en tests de son projet symfony, il faut choisir entre deux options :
Installer Symfony de façon centralisée sur le serveur et utiliser plusieurs projets dans (par exemple) /usr/share/php/symfony ou avoir une version de symfony incluse dans chaque projet.
Un symfony centralisé permet de garder une version à jour de façon plus pérenne pour l’ensemble de ses projets, c’est la solution la plus propre, elle permet en outre d’utiliser pear pour les mises à jour en une seule ligne de commande, bref : c’est propre, maintenable, facile, etc.
Dans la réalité, les versions de Symfony évoluent très vite, sur l’intranet, nous avons commencé avec la 1.1.1 et Seb est déjà en 1.1.5-DEV, par ailleurs, comme Sensio vient de recruter Jonathan Wage, le développeur principal de Doctrine, les prochaines versions de Symfony seront basées sur Doctrine, donc nos prochains projets symfony seront certainement en 1.3, voir 1.4 ou 1.5.
mettre à jour /usr/share/php/symfony/ alors que plein de projets en dépendent, c’est s’assurer à chaque mise à jour de l’impact sur les projets existants, c’est aussi être cantonné à une seule version de Symfony.
Pour l’intranet nous avons choisi 1.1.x pour sa maturité, en effet 1.2 me semblait un peu trop jeune pour ce genre d’applications. En revanche, pour les prochains projets (à partir de juin 2009) nous serons certainement amenés à utiliser Symfony 1.2 voir Symfony 1.3
La doc de Symfony conseille d’utiliser la commande freeze qui a été conçue spécialement à cet effet. Dans le chapitre déploiement d’applications, la doc donne toute la démarche à opérer (y compris l’utilisation de rsync).
En simple, voici la démarche à effectuer (merci garfield-fr de #symfony-fr)
Un cas pratique ? voir Mise en tests de mon projet Symfony 1.1