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 :

Premier truc à faire : mettre son projet en tests, grosso-modo, il faut suivre la procédure décrite dans la doc dans le chapitre Deploying Application.

Comme on n’a pas encore commencé à utiliser rsync, la bonne vieille méthode sera de commencer par dupliquer le projet  et le “nettoyer” :

cp -R IntraViva IntraViva-frozen

#nettoyage
cd IntraViva-frozen
rm -Rf ./.svn/
rm -Rf ./*/.svn/
rm -Rf ./*/*/.svn/
rm -Rf ./*/*/*/.svn/
rm -Rf ./*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/*/*/*/*/.svn/
rm -Rf ./*/*/*/*/*/*/*/*/*/*/*/.svn/
rm .project
ls -laR | grep svn
rm log/*.log
rm -Rf cache/*
rm -Rf web/uploads/*/*

Après, on utilise dans le nouveau dossier (la copie) la commande freeze

# freeze avec l'url de Symfony (cf ./config/ProjectConfiguration.class.php)
./symfony project:freeze /usr/share/php/symfony

L'édition des mots de passe dans deux fichiers (gnn, une subtilité m'échappe)

# changement des mots de passe
vi config/databases.yml config/propel.ini

Et comme je suis un bourrin, j'upload comme un porc et je fixe les droits, on est en dev alors pas de quartiers !

#upload bourrin (toupourri)
scp -r * user@serverdedev.net:./intraviva.serverdedev.net/

ssh user@serverdedevnet
chmod -R 777 config/ log/ web/upload/
# un chown serait plus propre mais le dev c'est le paradis des gorets.

$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

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

Mettre à jour ? rien de plus simple :

pear upgrade symfony/symfony-1.1.5

Mise en evidence

Voici ce qui se passe lorsque l’on charge une premiere fois la page:

1. Le DOM se charge, avec dedans la liste des commentaires existants
2. Des actions Javascript sont associees a ces commentaires (autrement dit, on bind ces commentaires).

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.

On fait quoi alors?

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!”); });

C’est moche non?

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?

Ou pas…

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.

• Planzone
• taskii

les deux sont assez similaires et apportent quelques bonnes idées.

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 :

1. L’utilisateur fait appel à un script situe sur un serveur interne au reseau.
2. Ce dernier, munit d’une base de données avec l’ip de l’utilisateur et son ID (ou via active directory) détermine l’utilisateur.
3. Le proxy communique au serveur WEB via XMLRPC les informations sur l’utilisateur.
4. Le serveur génère une clef qu’il renvoit par XMLRPC au serveur interne.
5. Le serveur interne redirige l’utilisateur vers une page d’authentification par clef (une simple action sfGuard) qui démarre automatiquement la session.

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

Un Symfony centralisé

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.

Un symfony par projet

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.

Rassembler symfony dans le projet

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)

Création d’une sandbox

Pour faire une sandbox :
1. copier symfony dans ./lib/vendor/symfony
2. modifier le ProjectConfiguration pour pointer sur ./lib/vendor/symfony

Travailler en sandbox avec svn

1. créer le dossier vendor dans le dossier lib
2. mettre symfony dans ./lib/vendor/symfony
3. svn pe svn:externals lib/vendor symfony http://svn.symfony-project.com/branches/1.1

Un cas pratique ? voir Mise en tests de mon projet Symfony 1.1