Comparer les valeurs “7.0″ et “10.0″ avec JavaScript

Dernièrement, j’ai eu à produire un correctif sur un script de détection de version de navigateur assez âgé. Ce script en particulier détectait quelques navigateurs en particulier afin de leur afficher un message comme quoi leur expérience de navigation serait optimale s’ils utilisaient une version récente de Firefox, Google Chrome ou Internet Explorer.

La principale faiblesse de ce script était qu’il faisait une détection de navigateur basée sur le numéro de version.

Une mise en contexte historique s’impose

Le quatre septembre 2012 fut la date où le navigateur Internet Explorer 10 a été mis à la disposition des internautes. Cette version d’Internet Explorer est celle qui respecte mieux les standards du web (HTML5 et CSS3). Sur papier, tout est parfait dans le meilleur des mondes. N’est-ce pas?

Là où j’ai eu à intervenir, est que cette fameuse détection de navigateur se faisait, disons-le, dans le mauvais sens du poil. Il a été mentionné que les visiteurs utilisant Internet Explorer 10 se faisaient présenter l’avertissement de navigateur que j’ai mentionné en introduction.

Tant pis pour eux que je me suis initialement dit. Toutefois, il fallait investiguer et trouver une solution permanente.

Une détection simpliste

À vrai dire, il s’agissait, à mon avis, de la pire méthode possible pour détecter la version du navigateur. C’est à dire, l’utilisation de la fonctionnalité jQuery.browser.

Truc de projQuery.browser est déprécié depuis déjà un bon moment. Ne l’utilisez plus. OK?

L’appel en question avait l’air de la chose suivante : jQuery.browser.msie && jQuery.browser.version <= ’7′. D’ailleurs, cette ligne en question est présente dans beaucoup de résultats Google.

Or, dans le cas du navigateur Internet Explorer 10, comparer la valeur de jQuery.browser.version à la chaîne ‘7‘ revient à la comparaison suivante : ‘10‘ <= ‘7‘. Exécutez cette comparaison dans la console JavaScript de votre navigateur. Le résultat retourné sera “True“.

10-7

À première vue, le résultat semble incohérent. N’est-il pas un peu étrange que 10 soit plus petit que 7? Si vous regardez comme il faut,vous remarquerez qu’il s’avère que ce sont deux chaînes qui sont comparées. Comment voulez-vous que le compilateur sache quoi faire avec?

À ce point-ci, je présume que l’auteur initial du script n’avait pas pensé qu’il avait affaire à des chaînes plutôt qu’à des nombres. Dans un cas comme celui-ci, JavaScript compare le premier caractère de chacune des chaînes pour déterminer le résultat de la comparaison. Au minimum, pour avoir été cohérent dans l’approche, il aurait fallu utiliser la fonction parseInt afin d’extraire la valeur numérique de la chaîne.

Au final, la comparaison en question revient à comparer les valeurs de 1 <= 7. Ce qui donne le résultat cité plus haut.

La bonne façon

J’ai précédemment mentionné que la détection du navigateur basé sur le numéro de la version était la pire des façons de déterminer à quel navigateur vous avez affaire.

Dans le meilleur des mondes, il est préférable d’opter pour une stratégie détection de fonctionnalité dans le cas où vous désirez viser certains navigateurs anciens. La principale raison de cela est que jQuery.Browser est déprécié depuis la version 1.3 de jQuery et n’existe plus depuis la version 1.9 (la version courante).

Par exemple, dans le cas qui nous intéresse, la détection d’Internet Explorer 7 aurait pu se faire par la détection du  support de certaines propriétés CSS ou fonction reliée au DOM HTML tel que suggéré par Mozilla. Il y a même certaines stratégies plus avancées qui sont suggérées par ce billet.

Parlant de détection de navigateurs, Microsoft a même une page dédiée à la détection d’Internet Explorer. Vous pourriez vous laisser tenter et suivre leurs conseils afin de vous assurer que vos visiteurs utilisent bien Internet Explorer.

Les liens de la semaine – Édition #35

Développement

.NET

Technologie

Web

Science et autres

Intégration de la révision Git à son projet Visual Studio 2012

Vous vous souvenez de mon billet qui traitait de l’intégration du numéro de révision SVN à son projet Visual Studio? Ce billet documentait une avenue que j’ai préconisée afin de m’assurer que le numéro de révision SVN soit toujours présent au moment du déploiement de mon site web.

La technique utilisée, dans ce billet, consistait à utiliser l’événement de précompilation du projet web et extraire la révision courante pour le rendre disponible dans un fichier texte accessible à la racine du site web.

Évidemment, le principal désavantage de cette solution est qu’elle est spécifique au gestionnaire de code source SVN.

Et Git, lui?

Comme le camarade Olivier l’a mentionné. Qu’est-ce qu’il advient de Git, lui? C’est exactement là où je voulais en venir! Après tout, à part pour le travail, j’utilise uniquement Github pour entreposer mon code.

Un gestionnaire différent, autres mœurs?

Lorsque j’ai entrepris d’élaborer, la solution Git, je savais que je ne pourrais pas emprunter le même chemin que celui emprunté pour SVN. Après tout, je n’ai pas accès à TortoiseSVN pour extraire la version courante.

Ceci étant dit, la façon de procéder doit être la même, car c’est au moment de la compilation que doit se faire l’opération de récupérer le numéro de version. C’est aussi à cette étape que vous pourriez, par exemple, décider d’inclure le numéro de révision à même votre fichier AssemblyInfo.cs.

La recette

Au bout du compte, j’ai besoin d’identifier au minimum trois informations dans mon fichier version.txt.

  • La date de la compilation
  • La branche utilisée pour cette version
  • La révision utilisée.

La façon la plus simple d’y arriver est d’avoir un script Powershell qui va aller extraire cette information du dossier courant. Ce script est composé des trois éléments permettant de retrouver les trois informations mentionnés ci-haut.

Ces trois informations sont séparées par le caractère “-”. Les données extraites sont représentées de la façon suivante : “2013-06-06 20:44:02 – master – 450fad1“.

En supplément, vous devez avoir la commande suivante dans vos événements de précompilation : powershell.exe $(ProjectDir)\Build\git-version-extract.ps1 -FilePath $(ProjectDir)\version.txt.

Note : vous devez absolument exécuter votre instance de Visual Studio en mode administrateur pour que cette configuration fonctionne.

Un petit pas pour l’avenir

L’exemple que j’ai mis en place est une façon de faire parmi tant d’autres. D’ailleurs, elle pourrait être utilisée à d’autres sauces.

Je donne l’exemple du fichier AssemblyInfo qui pourrait être généré de cette façon pour votre application. Dans mon cas, je préfère avoir accès à un fichier qui est accessible même lorsque mon site est mort. Toutefois, vous pourriez avoir besoin de cette information dans votre historique d’erreurs, par exemple.

Les liens de la semaine – Édition #34

Développement

Web

.NET

  • Un nouveau View Engine est en train de voir le jour pour ASP.NET MVC : Parrot for ASP.NET. Son design vise à minimiser l’utilisation de code dans vos vues.
  • Une introduction au projet ScriptCS. Vous apprendrez comment vous pouvez le configurer et l’utiliser sur votre poste de travail. ScriptCS permet l’exécution de code C# sans avoir à utiliser Visual Studio.

Technologie

Science et autres

Comment recycler un Application Pool IIS à partir de la ligne de commande

L’optimisation de tâches récurrentes est, à mon avis, l’endroit où vous avez les plus grandes chances d’économiser du temps. En particulier sur les tâches du quotidien.

Le recyclage de son Application Pool est l’un des maux nécessaires qu’un développeur ASP.NET doit faire face. En général, en cours de développement, un pool est recyclé automatiquement et il n’y a aucun besoin de s’en soucier. Le recyclage lorsqu’il y a des changements aux fichiers et dossiers suivants :

  • Web.config
  • Machine.config
  • Global.asax
  • le dossier /Bin
  • App_Code

En théorie, tout va bien dans le meilleur des mondes. Parfois, il y a des cas où l’on dirait que cela ne fonctionne pas et qu’il y a quelque chose en mémoire qui colle, malgré tout.

C’est alors que le développeur ASP.NET va sortir la bombe nucléaire de son arsenal : recycler le pool manuellement.

Pour y arriver, il faut passer par la console de gestion IIS, sélectionner le sous-menu de navigation Application Pools, sélectionner son pool, faire un clic droit sur celui-ci et sélectionner “Recycle”.

Quand ça arrive quelques fois par jour, on s’entend que cela est répétitif.

Automatisation

Ce que je propose est tellement simple que je ne m’étonne pas encore d’y avoir pensé avant. La situation se divise en deux volets que voici.

Création d’un script

Sur votre disque dur, à votre endroit préféré, créer un fichier .bat et allez y coller la ligne de commande suivante :

appcmd recycle apppool /apppool.name:LE_NOM_DE_VOTRE_POOL

Si vous l’exécute manuellement cette commande, vous réaliserez que votre Application Pool sera recyclé.

Création d’un raccourci

L’étape suivante est de créer un raccourci permettant d’exécuter cette commande à l’aide d’un clic à portée de main. L’endroit de prédilection pour ce clic est dans la barre de tâche de Windows.

Or, il n’est pas possible d’insérer dans la barre de tâches un fichier .bat directement. Il faut créer un raccourci vers celui-ci pour l’ajouter à la barre de tâche par la suite. En bonus, selon son emplacement dans la barre de tâche, vous pouvez y accéder avec la touche Windows. Par exemple, Windows+1 vous permettra d’accéder à la première icône et ainsi de suite.

Et n’espérez pas avoir les instructions pour créer un raccourci vers votre barre de tâches sur ce blogue. Vous ne l’aurez pas!

En espérant que cela vous soit (possiblement pas) utile!

Suivre

Get every new post delivered to your Inbox.

Join 479 other followers