Le piège JavaScript avec undefined

C'est sûre que vous déjà utilisé la propriété undefined en JavaScript pour vérifier si une variable a été assignée. Soit l'exemple:

var app = new Object();
var a = '';
var b;

app.isDefined = function(value){
   return value !== undefined;
}

console.log( app.isDefined(a) ? 'defined' : 'undefined' );
console.log( app.isDefined(b) ? 'defined' : 'undefined' );

Logiquement, On s'attend à ce que la variable 'a' soit définie alors que 'b' ne le soit pas Mais qu'arriverait-t-il si on définissait volontairement une variable undefined dans ce script ou involontairement lors de l'inclusion d'une librairie externe ? Le concept de closure viendrait introduire une vulnérabilité :

var app = new Object();
var a = '';
var b;

var undefined = 4; // oups...

app.isDefined = function(value){
   return value !== undefined;
}

console.log( app.isDefined(a) ? 'defined' : 'undefined' );
console.log( app.isDefined(b) ? 'defined' : 'undefined' );

Dans ce cas-ci, les deux appels retourneraient 'defined'.

L'idéal serait de ne jamais se fier à la propriété undefined, à moins de la redéclarer à l'intérieur de la fonction qui compte l'utilise.Ainsi, on évitera les mauvaises surprises reliées à ce genre de pratique.
  
var undefined = 4; // ok
app.isDefined = function(value){
   // sans danger pour le undefined dans la portée globale
   var undefined;
   return value !== undefined;
}

Ajout d’un virtual host pour un projet symfony

  Cet article se trouvait quelque part dans mes brouillons il y a pas mal de temps mais je ne trouvais pas le temps de l’adapter pour le blog.. Voilà je me retrouve de nouveau avec un projet symfony alors je me suis dit que c’est le moment de le mettre.
  Je commence par expliquer le résonnement pour configurer un virtual host sur un serveur local. Et ensuite je passe à la configuration du serveur pour un projet symfony.

1. Ajout d’un virtual host sur un serveur local

  Lorsqu’on développe des projets personnels, on utilise souvent le poste de travail comme laboratoire et on accède à nos différents projets à partir de http://localhost (127.0.0.1).
  Cependant, plutôt que de créer chaque projet dans un répertoire à la racine du répertoire www d'Apache, je préfère utiliser ce qu'on appele un hôte virtuel (VirtualHost ou vhost). Je peux donc placer mes projets à différents endroits sur mon poste. Pour chaque projet, je crée ensuite un sous-domaine à localhost. Par exemple si mon premier projet est placé dans www : http://localhost/projet1/ deviendra http://projet1.localhost/. Ainsi, je peux continuer à programmer en utilisant la racine du répertoire comme référence, comme si le projet était en ligne sur son propre nom de domaine.
  Voici la configuration possible pour Apache:
  1. D'abord, je crée deux projets, le premier dans le répertoire www d'Apache, le deuxième à un autre endroit, par exemple sur la partition D:
  2. On doit accéder au fichier httpd.conf d'Apache (C:\Program Files\EasyPHP 2.0b1\conf_files\) et s'assurer que la ligne suivante n'est pas commentée :
        Include conf/extra/httpd-vhosts.conf
  3. Ouvrez le fichier httpd-vhosts.conf (C:\Program Files\EasyPHP 2.0b1\apache\conf\extra\) et ajouter un hôte virtuel pour chaque projet :

NameVirtualHost *:80

<VirtualHost *:80>
DocumentRoot "C:\Program Files\EasyPHP 2.0b1\www\projet1"
ServerName projet1.localhost
</VirtualHost>

<VirtualHost *:80>
DocumentRoot D:\Programmation\Web\projet2
ServerName projet2.localhost

</VirtualHost>

  4. Dans le fichier hosts (Sous XP : C:\WINDOWS\system32\drivers\etc\), ajoutez une ligne pour chaque projet :

127.0.0.1 projet1.localhost

127.0.0.1 projet2.localhost

  5. Redémarrez Apache (pour que la nouvelle configuration prenne effet. EasyPHP a un raccourci pour le redémarrer à partir du système tray)
6. Ouvrez un invite de commande et exécutez la commande suivante  :
            ipconfig /flushdns
 7. À partir de votre fureteur préféré, tester l'accès à http://projet1.localhost et à http://projet2.localhost. Le tout devrait maintenant fonctionner.

  Bien entendu, il s'agit d'une configuration de base alors j'ai volontairement omis certains détails qui auraient pu être inclus.
  
     2. Configuration d’un serveur web pour un projet symfony
  
  Pour un projet symfony, il est préférable de configurer des serveurs virtuels plutôt que d'ajouter un nouveau port à chaque fois qu’on démarre un nouveau projet. Au lieu de choisir un port et d'ajouter une déclaration Listen, on choisit un nom de domaine (par exemple le nom du domaine réel avec .localhost ajouté à la fin) et ajouter une déclaration ServerName :

# C'est la configuration pour votre projet

<VirtualHost 127.0.0.1:80>

ServerName www.monprojet.com.localhost

<!-- same configuration as before -->

</VirtualHost>

Le nom du domaine www.monprojet.com.localhost utilisé dans la configuration d'Apache doit être déclaré localement. Ce fichier se trouve dans le répertoire :

C:\WINDOWS\system32\drivers\etc\.

On ajoute la ligne suivante :

127.0.0.1 www.monprojet.com.localhost

Autre méthode peu commode est d’ajouter un port d’écoute Listen avant de déclarer notre host dans dans le fichier httpd.conf de Apache :

Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>

DocumentRoot "d:\wamp\www\monprojet\web"

DirectoryIndex index.php

<Directory "d:\wamp\www\monprojet\web">

AllowOverride All

Allow from All

</Directory>

Alias /sf "C:\wamp\php\PEAR\pear\data\symfony\web\sf"

<Directory "C:\wamp\php\PEAR\pear\data\symfony\web\sf">

AllowOverride All

Allow from All

</Directory>

</VirtualHost>

L'alias /sf donne accès à des images et des fichiers JavaScript nécessaire pour afficher correctement les pages symfony par défaut et la barre d'outils web de débogage. Cette configuration permet à Apache d'écouter le port 8080 sur la machine, de sorte que le site web sera accessible à l'adresse suivante :

http://~localhost~:8080/

On peut changer 8080 par un autre nombre, mais on doit favoriser des nombres plus grand que 1024 car ils ne nécessitent pas de droits administrateurs.