Pims Labs » PHP http://labs.pimsworld.org Les labs de Pims World Thu, 28 May 2009 08:15:39 +0000 http://wordpress.org/?v=2.7.1 en hourly 1 Fichiers CSV http://labs.pimsworld.org/2009/02/fichiers-csv/ http://labs.pimsworld.org/2009/02/fichiers-csv/#comments Fri, 06 Feb 2009 15:06:08 +0000 Adrien http://labs.pimsworld.org/?p=397 Déjà eu des problèmes à lire un fichier d’export au format CSV ?
Voici le formattage assurant un maximum de compatibilité :

  • utiliser l’extension “.csv”
  • utiliser des délimiteurs de champs pour toutes les lignes du fichiers, généralement ce sont les doubles guillements (”) qui sont utilisés
  • si une valeur de champ contient le délimiteur de champ, le doubler, exemple: “Voici un caractère “” dans un champ du fichier”
  • utiliser le point-virgule “;” comme séparateur de champ
  • terminer les lignes par le caractère “\n”
  • supprimer toute occurrence du caractère “\r” dans le fichier (mal supporté par Windows)

J’ai également rencontré des problèmes avec l’encodage unicode UTF-8  et Microsoft Office Excel (il n’a pas l’air de vouloir le lire et force l’encodage ISO) mais je n’ai pas trouvé de solution.

Post scriptum: n’essayez même pas d’assurer une compatibilité avec les versions antérieures à Micorsoft Office Excel 98

]]> http://labs.pimsworld.org/2009/02/fichiers-csv/feed/ Xoad et le Zend Framework http://labs.pimsworld.org/2009/01/xoad-et-le-zend-framework/ http://labs.pimsworld.org/2009/01/xoad-et-le-zend-framework/#comments Tue, 27 Jan 2009 17:53:24 +0000 jrm http://labs.pimsworld.org/?p=162 Dans cet article vous allez découvrir comment XOAD permet d’exporter des classes PHP vers du code Javascript par l’intermédiaire du Zend Framework.

Ce qu’il faut savoir pour comprendre cet article :

  • Avoir de bonnes bases en javascript, PHP.
  • Comprendre le design pattern MVC.
  • Savoir créer le bootstrap d’une application avec le Zend Framework.

Xoad

Xoad permet d’exporter des objets du côté serveur vers le côté client. Xoad est un environnement basé sur un ORB. Un ORB (Object Request Broker) est un ensemble de fonctions qui implément un bus logiciel par lequel des objets envoient et reçoivent des requêtes et des réponses, de manière transparente et portable.

Zend Framework

Le Zend Framework est un framework pour PHP 5 créé par Zend. Il est distribué sous la New BSD license. Le Zend Framework, aussi nommé ZF, a été développé dans le but de simplifier le développement Web tout en recommandant les bonnes pratiques et la conception orientée objets en offrant des outils puissants aux développeurs. ZF permet aussi d’utiliser nativement le principe de MVC (Modèle-Vue-Contrôleur) mais ne l’oblige pas.

Préalable

Configuration du Zend-Framework :

Si vous êtes débutant avec le ZF vous pouvez vous reporter à l’arcticle suivant : Premier pas avec le ZF .

Considérons l’arborescence suivante :

/application/
  Lab/
    controllers/
      LabController.php
    views/
      scripts/
        lab/
           xoad.phtml
    Xoad.php
/deploy/
  index.php (bootstrap)
/lib/
  Zend/
  xoad/

Vous pouvez télécharger la librairie XOAD ici.
Nous allons créer une vue qui va nous permettre d’afficher le traditionnel “Hello world” lors du clique sur un bouton.

xoad.phtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
    <head>
        <title>Zend & XOAD tutorial</title>
                    <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />
        <base href="http://localhost/earl/deploy/"/>
        <script type="text/javascript" src="public/lab/xoad_optimized.js"></script>
        <script type="text/javascript">
           var Lab_Xoad = <?php echo $this->jsObject ?>;
        </script>
    </head>
<body>
<input type="button" id="hello-world" value="Hello World !">
<script type="text/javascript">
document.getElementById('hello-world').onclick = function ()
{
    alert(Lab_Xoad.test());
};
</script>
</body>
</html>

Dans cette vue, rien d’extraordinaire :
- inclusion de la librairie javascript xoad (optimisée)
- affichage de l’objet javascript généré côté serveur et passé à la vue.

var Lab_Xoad = <?php echo $this->jsObject ?>;

- ajout d’un évènement sur le onclick d’un bouton qui va nous permettre d’afficher la réponse générée par xoad.

LabController.php

<?php
class Lab_LabController extends Zend_Controller_Action
{
   
  /**
     * Specific view
     *
     * @var Zend_view
     */
   
    private $_view = null;
   
  /**
     * Init zend view.
     *
     * @return void
     */
    public function init()
    {
        $this->_view  = new Zend_View();
        $this->_view->setScriptPath(dirname(dirname(__FILE__))  . '/views/scripts/');
    }
   
  /**
     * Xoad tutorial action.
     *
     * @return void
     */
    public function xoadAction()
    {
        Zend_Loader::loadClass('Lab_Xoad');
        define('XOAD_AUTOHANDLE', true);
        require_once 'xoad/xoad.php';
        $this->_view->jsObject = XOAD_Client::register(new Lab_Xoad(),'lab/lab/xoad');
       
        // Render content
        echo $this->_view->render('lab/xoad.phtml');
    }
}

Ce controller va nous permettre d’effectuer le rendu de notre vue décrite plus haut.
La méthode init nous permet de créer une vue personnalisée.
La méthode xoadAction va permettre à Xoad d’interagir avec le Zend Framework.
Particularités :
- On force le chargement de la class Lab_Xoad avec le Zend_Loader.
- On inclut la librairie xoad (située dans le repertoire lib)
- On génère l’objet javascript à partir de la méthode statique “register” en lui passant en premier paramètre la classe et en second l’url de callback utilisée par xoad
- Le fait de définir à true la constante XOAD_AUTOHANDLE permet à xoad de déterminer si l’action du controller a été appelé lors d’une requête ajax ou non, dans le cas d’une requête Ajax le script s’arrête après le require_once de la librairie xoad, le format de retour est alors du json qui servira comme outil de communication à notre objet js.

Xoad.php

<?php
class Lab_Xoad
{
    public function test()
    {
        return 'Hello world !';    
    }
}

C’est là que ça commence à devenir interessant !

En effet, cette class va pouvoir être utilisée directement en javascript sans avoir à le modifier.
Toutes ses méthodes et ses attributs sont directement disponibles en javascript.
Vous n’avez plus à vous soucier d’écrire le code Javascript qui va se charger d’effectuer des requêtes Ajax et d’en traiter le retour.
Exemple, dans notre vue nous appelons directement la méthode suivante :

alert(Lab_Xoad.test());

Cet appel Javascript va nous retourner “Hello World”, les aller-retours serveur nécessaires vont se faire en backend.

Alors convaincu ?

]]> http://labs.pimsworld.org/2009/01/xoad-et-le-zend-framework/feed/ Tests unitaires avec Zend Studio http://labs.pimsworld.org/2009/01/tests-unitaires-avec-zend-studio/ http://labs.pimsworld.org/2009/01/tests-unitaires-avec-zend-studio/#comments Mon, 19 Jan 2009 18:09:02 +0000 Kal http://labs.pimsworld.org/?p=10 Si vous êtes persuadés de l’intérêt des tests unitaires pour vos développements PHP mais que vous n’avez jamais osé franchir le pas, ce tutoriel est fait pour vous. Afin de migrer en douceur vers les préceptes sacrés de l’eXtreme Programming je vous propose un exemple concret de mise en place des tests unitaires sous l’environnement Zend Studio.

Pour ce faire, nous allons implémenter une bonne vieille pile LIFO en PHP.

Après avoir crée un projet avec Zend Studio et une classe Unit_Stack, on commence par écrire le squelette de cette classe :

/**
* A LIFO Stack
*/
class Unit_Stack
{
    /**
    * Push an item.
    *
    * @param mixed $item
    *
    * @return void
    */
    public function push($item)
    {}
   
    /**
    * Pop an item.
    *
    * @return mixed
    * @throws Exception if stack is empty.
    */
    public function pop()
    {}
   
    /**
    * Count items of stack.
    *
    * @return int
    */
    public function count()
    {}
   
    /**
    * Tells if stack is empty.
    *
    * @return boolean
    */
    public function isEmpty()
    {}
   
    /**
    * Removes all items of stack.
    *
    * @return void
    */
    public function reset()
    {}
}

Les commentaires devraient suffire à expliquer ce qu’est sensée faire cette classe.

L’étape suivante consiste à créer la classe de tests unitaires ou Test Case. Dans l’arborescence tests/unit/Unit/, faire click droit puis new -> PHPUnit Test Case.

Il suffit alors de choisir la classe à tester via le bouton Browse en face de ‘Element to Test’, puis de corriger le nom de la classe de Test générée dans le champ ‘Test File Name’ en virant le préfixe Unit_’. Cela devrait ressembler à ça :

Création d'un Test Case

Création d'un Test Case

Le Test Case généré devrait comprendre :

  • une méthode setUp : lancée avant chaque test.
  • une méthode tearDown : lancée après chaque test.
  • un constructeur : pas vraiment utile.
  • une méthode de test par méthode publique de la classe à tester.

Dans le cadre de cet exemple, je vous invite à supprimer le constructeur ainsi que les méthodes setUp et tearDown.

Nous rentrons maintenant dans le vif du sujet, il s’agit :

  1. d’écrire un test
  2. de lancer le Test Case afin de vérifier (oh surprise) qu’il échoue
  3. d’implémenter la fonctionnalité
  4. de relancer le test et éventuellement corriger jusqu’à ce que le test passe !

Écriture du test

Nous proposons pour la méthode isEmpty l’écriture du test suivant :

public function testIsEmpty ()
{
    $stack = new Unit_Stack();

    // a new stack is empty !
    $this->assertTrue($stack->isEmpty());
}

Lancer le Test Case

Il suffit d’un click droit sur le fichier du Test Case puis de choisir Run as -> PHPUnit Test

Si tout se passe bien, le test devrait apparaître en erreur et les autres en non implémentés.

Résultats test case

Résultats test case

Implémenter la fonctionnalité

public function isEmpty()
{
    return empty($this->_array);
}

Trop facile …

Relancer le test et corriger

Même procédure que le lancement précédent, cette fois le test devrait apparaître comme réussi.

Ensuite….

Il suffit de refaire la même procédure itérativement pour chaque fonctionnalité. A mesure que les nouvelles fonctionnalités sont implémentées, de nouveaux tests peuvent être écrits en plus de ceux générés par Zend Studio. Il suffit de créer une méthode publique dont le nom commence par test.

Si votre application contient plusieurs classes et donc plusieurs Test Case (ce qui est souvent le cas !), il peut être fastidieux de lancer les tests cases un par un, il est alors intéressant d’utiliser les Tests Suites. Il suffit de faire un click droit dans Zend studio sur le répertoire test/unit/ puis New -> PHPUnit Test Suite.

On sélectionne alors les Tests Case à lancer puis finish. Une Suite se lance alors de le même façon qu’un Test Case.

Liens :

]]> http://labs.pimsworld.org/2009/01/tests-unitaires-avec-zend-studio/feed/ Phing automatise les opérations répétitives des développements PHP http://labs.pimsworld.org/2009/01/phing-automatise-les-operations-repetitives-des-developpements-php/ http://labs.pimsworld.org/2009/01/phing-automatise-les-operations-repetitives-des-developpements-php/#comments Wed, 14 Jan 2009 11:09:18 +0000 Stéphane Roucheray http://labs.pimsworld.org/?p=74 L’automatisation des opérations répétitives dans un projet de développement peut être résolue de multiples manières allant du simple script lancé à la main au système d’intégration continue.

La plupart des langages ont standardisé leurs outils, make pour C, Ant pour Java… PHP bénéficie lui aussi d’un tel outil : Phing.

Phing est un projet Open Source très inspiré de Ant. Le concept est assez simple. Un fichier XML décrit une série d’actions possibles pouvant ou non être dépendantes les unes des autres et une ligne de commande permet de déclencher ces actions.

Utilisation de Phing

Un exemple rapide. Nous voulons vérifier que la syntaxe des fichiers PHP de notre projet est bien respectée, qu’aucune erreur ne s’y est glissée, le fichier XML ressemble alors à ça :

Fichier build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="premier_projet" default="lint">
    <target name="lint" description="Vérifie la syntaxe PHP">
        <phplint>
            <fileset dir="/home/mon_projet/src/">
                <include name="**/*.php"/>
                <exclude name="lib/Zend/**/*.php"/>
            </fileset>
        </phplint>
    </target>
</project>

Enregistrez ce fichier avec le nom build.xml (le fichier par défaut utilisé par phing) dans le dossier build de votre projet, par exemple

/home/mon_projet/build/

Ouvrez une console et lancez ensuite la commande phing depuis le dossier du fichier build.xml

Commande

cd /home/mon_projet/build/
phing

Le fichier build.xml est très explicite, cette commande va donc vérifier, pour tous les fichiers PHP de mon dossier source a l’exclusion de ceux de la bibliothèque Zend, que leur syntaxe est bien respectée.

Autre exemple, pour générer automatiquement la documentation de classes PHP.

Fichier build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="premier_projet" default="doc">
    <target name="doc" description="Génère la documentation">
        <phpdoc title="API Documentation"
                destdir="/home/mon_projet/api"
                sourcecode="no" output="HTML:Smarty:PHP">
            <fileset dir="/home/mon_projet/src/">
                <include name="**/*.php"/>
                <exclude name="lib/Zend/**/*.php"/>
            </fileset>
        </phpdoc>
    </target>
</project>

Commandes

cd /home/mon_projet/build/
phing

Phing tout comme Ant gère la dépendance des tâches. Dans notre cas, si nous voulons générer la documentation après la vérification syntaxique. Il suffit de modifier notre fichier build.xml comme suit :

Fichier build.xml

<?xml version="1.0" encoding="UTF-8"?>
    <project name="premier_projet" default="build">
        <target name="lint" description="Vérifie la syntaxe PHP">
            <phplint>
                <fileset dir="/home/mon_projet/src/">
                    <include name="**/*.php"/>
                    <exclude name="lib/Zend/**/*.php"/>
                </fileset>
            </phplint>
        </target>

        <target name="doc" description="Génère la documentation">
            <phpdoc title="API Documentation"
                        destdir="/home/mon_projet/api"
                        sourcecode="no"
                        output="HTML:Smarty:PHP">
                <fileset dir="/home/mon_projet/src/">
                    <include name="**/*.php"/>
                    <exclude name="lib/Zend/**/*.php"/>
                </fileset>
            </phpdoc>
        </target>

        <target
            name="build"
            depends="lint, doc"
            description="Syntaxe PHP et Documentation" />
    </project>

Commande

phing

La commande phing va automatiquement séquencer les 2 tâches lint et doc car la tâche build dépend d’elles.
Si nous voulons seulement générer la documentation il suffit de taper la commande suivante.

Commande

phing doc

Phing est très puissant. Il permet de gérer des tâches conditionnelles, des tâches spécifiques PHP comme l’analyse de code par le compilateur Zend, le lancement de tests unitaires classiques ou avec Selenium. Il sait aussi piloter des tâches plus génériques comme l’update de dépôt SVN ou l’exécution de commandes externes. La liste longue et complète des tâches disponibles se trouve dans la documentation de Phing.

Installation de Phing

Pour installer Phing, le plus simple est d’utiliser PEAR. Sous Ubuntu tapez les commandes suivantes en mode super utilisateur.

Installation de PEAR, la bibliothèque d’extensions à PHP

apt-get install php-pear

Installation de Phing

pear channel-discover pear.phing.info
pear install phing/phing

On en parle ailleurs…

Un article en anglais de Nabeel Shahzad décrit comment il s’est débarrassé des scripts grâce à Phing

]]> http://labs.pimsworld.org/2009/01/phing-automatise-les-operations-repetitives-des-developpements-php/feed/ Css pour les infobulles de Google Map http://labs.pimsworld.org/2009/01/css-pour-les-infobulles-de-google-map/ http://labs.pimsworld.org/2009/01/css-pour-les-infobulles-de-google-map/#comments Thu, 08 Jan 2009 13:59:27 +0000 clement http://labs.pimsworld.org/?p=45 Google Map permet grâce à sa librairie de créer des cartes personalisées, autant par leur contenu que par leur interface.

Les styles des “markers” (”GMarker”, “GIcon”), zones (”GPolygons”, “GPolyline”) sont facilement modifiables en javascript grâce à la multitude de méthodes prédéfinies par Google.

Malheureusement, il n’existe pas encore de solutions par défaut permettant de modifier en javascript le style des infobulles (infobulles s’affichant au-dessus d’un marker).

Pour contourner ce problème, un développeur, du nom de Joe Monahan, a ajouté à la librairie Open Source de Google Map, un fichier javascript (extinfowindow.js) permettant de modifier le css de l’infobulle.

Il suffit en fait d’insérer ce fichier javascript après l’appel de la librairie de Google Map. Ensuite, il faut changer après chaque création d’un marker et ajout d’un évènement la méthode classique “openInfoWindow()” par “openExtInfoWindow()”. Voici un exemple de l’appel à cette méthode :

GEvent.addListener(marker, “click”, function() { marker.openExtInfoWindow(map,”geolocalisation”,html); });

**marker : marker instancié (GMarker)

**map : carte instancié (GMap2)

**”geolocalisation” : nom de la div qui sera créée pour l’infobulle et utilisée pour modifier le style du css

**html : code html qui sera affiché dans l’infobulle

Il faut également inclure un fichier css. En fait, chaque zone de l’infobulle est définie par une nomenclature à respecter dans le css. Le nom de la div “geolocalisation” est très important, puisqu’il sert de préfixe pour toutes les div dans le fichier css.

Il existe d’autres méthodes intéressantes avec extinfowindow.

Pour une meilleure compréhension, je vous invite à visiter cette page d’exemples, mais aussi cette page de présentation.

]]> http://labs.pimsworld.org/2009/01/css-pour-les-infobulles-de-google-map/feed/