Javascript
zUploader est de sortie !
Voilà, le projet secretolol est enfin dévoilé après 3 (ou 4 ?) semaines de labeur, je vous laisse découvrir ça sur le topic dédié.
Non, je n’ai pas fait de page dédiée pour ce projet vu que ce n’est qu’une version alpha pour le moment.
Nes’
innerHTML, t’es une ordure !
Oui, le titre peut surprendre mais il est justifié.
Mais avant tout, une petite explication pour ceux qui ne codent pas en Javascript : innerHTML est une propriété qui existe sur tous les éléments qui sont des balises paires (une balise d’ouverture et une de fermeture), elle permet de modifier le contenu de cet élément de façon très simple, en effet, il suffit de faire ceci :
Et cela aura pour effet d’insérer le texte “Test” entre les balises d’ouverture et de fermeture de l’élément. Ainsi on peut modifier le contenu d’un élément bien plus facilement qu’avec le DOM (plus lent et plus long à écrire, mais pourtant bien plus puissant).
Bref, je ne suis pas un fan absolu de innerHTML mais il faut reconnaître qu’il est bien utile des fois, notamment quand on veut insérer pas mal de balises et de texte en Javascript. Seulement, voilà, dernièrement j’ai réalisé un code de ce genre :
element.firstChild.value = ‘Test’;
element.innerHTML += ‘<input type="button" value="Sauvegarder" />’;
Et soudain…
Mon premier input ne contient pas le texte défini !! Mais pourquoi ?! En fait il se trouve que la propriété value n’est pas enregistrée dans le innerHTML, ce qui fait que lorsque j’écris :
C’est comme si j’avais écrit :
Voilà pourquoi mon texte n’apparaît pas, le innerHTML contient ce que l’on peut voir dans le code source généré, pas plus. Alors pour la propriété value ce n’est pas vraiment un problème car je peux faire ça :
Là j’ai écrit la valeur directement dans le innerHTML, elle est donc sauvegardée. En revanche, pour des évènements créés par le biais du DOM-0 ou le DOM-2 c’est déjà plus problématique…
Alors certains me diront que c’était évident mais que voulez-vous, on ne peut pas toujours penser à tout ! =p
Au final le meilleur moyen pour définir des propriétés qui n’apparaissent pas dans le innerHTML c’est d’utiliser le DOM, mais attention à ne pas faire comme moi : Sur un même élément, si vous ajoutez quelque chose à l’aide du DOM puis que vous faites une concaténation de la propriété innerHTML comme je l’ai fait plus haut alors ça ne fonctionnera pas.
Sur ce, je retourne coder un projet secretolol.
Nes’
PS : Je trouve que cet article est super mal rédigé, si vous êtes de cet avis alors jetez-moi des pierres T_T
Un site sans connexion Internet ? Google Gears arrive !
Parlons un peu de Google aujourd’hui ! (D’ailleurs je fais une petite parenthèse pour vous signaler que Talus a des vidéos sur une conférence Google, si ça vous branche allez voir l’article concerné)
Je ne vais pas vous parler de la firme en général mais plutôt d’un de ses produits qui est encore en version bêta : Google Gears !
Je vous vois déjà venir : “De quoi s’agit-il ? Et pourquoi ça me dit (peut-être) quelque chose ?”
Bon, tout d’abord si cela vous dit (peut-être) quelque chose c’est parce que Wordpress l’utilise, mais ça ne vous explique pas son utilité hein ?
Il s’agit d’un plugin web que l’on peut installer sur n’importe quel OS et qui vient s’intégrer à votre navigateur (dans la liste de ceux compatibles bien sûr : IE, Firefox, Chrome, Safari). Son intérêt réside avant tout dans la possibilité de sauvegarder votre site web sur le PC de l’utilisateur et ainsi permettre son affichage même sans connexion à Internet.
Venons-en au détail :
Google Gears est composé de 3 modules principaux (et plusieurs autres “secondaires”) ayant chacun une fonction bien spécifique :
- LocalServer : Mot à mot, il s’agit d’un serveur local, mais en fait ce n’est pas exactement ça, il s’agit surtout d’un simple espace de stockage car il est incapable d’exécuter le moindre code PHP, tout doit passer par le Javascript (et cay bien). En fait on peut l’assimiler à un gestionnaire SVN car il récupère les fichiers (automatiquement ou manuellement) qui ont été mis à jour sur le site web de l’application (d’ailleurs il ne récupère que les fichiers mis à jour, donc ça évite les téléchargements superflus =p ).
- Database : Je pense que vous avez compris, il s’agit effectivement d’une base de données. Celle-ci est accessible par le biais du Javascript et est basée sur SQLite donc il n’y a pas de quoi s’inquiéter : On peut faire autant de choses qu’avec une BDD classique.
- WorkerPool : Alors ça j’ai mis un moment avant de comprendre son utilité, il s’agit d’un gestionnaire de tâches asynchrones. Plus simplement, ce module permet de lancer des tâches en arrière-plan afin de ne pas bouffer tout le proco. Mais qu’est-ce que ça vient foutre là en fait ? C’est quoi le rapport ? Eh bien il se trouve que c’est déjà utile rien que pour le téléchargement des fichiers sur le serveur local, sans lui l’interface se bloquerait.
Il a aussi d’autres utilités mais c’est le module que j’ai le moins étudié pour le moment donc je peux pas vous dire grand chose de plus.
Il y a aussi quelques autres modules mais un peu plus secondaires, on peut citer parmi eux celui qui permet de créer des icônes de raccourci sur le Bureau, dans la barre de lancement rapide ainsi que dans le menu Démarrer, il y a aussi un système de géolocalisation qui fonctionne bien mais dont je ne comprends pas l’utilité…
Bref, bien qu’étant encore en version bêta (v0.5.4.2 à l’heure où j’écris ces lignes), Google Gears est pour le moment très complet. Et d’ailleurs c’est bien pour cela que j’ai commencé à m’y intéresser. Tiens, puisqu’on parle de ça on va voir un peu “la partie code”.
Tout d’abord, je tiens à féliciter l’équipe de développeurs pour leur Doc qui est très complète, j’ai pas eu de gros problèmes pour apprendre à me servir de Gears (faut comprendre l’anglais technique quoi…).
La structure de Google Gears est plutôt bien réalisée, on a une classe d’ensemble (nommée “factory” mais qui sera peu à peu abandonnée dans la version finale de Gears) qui permet de créer un objet pour chaque module (Localserver, Database, etc…). Et chacun de ces objets possède des méthodes et des attributs permettant de gérer le domaine qui leur est attribué.
Comme je m’explique mal je vais faire un exemple pour le serveur local :
var localserver = google.gears.factory.create(‘beta.localserver’);
// On ouvre maintenant le gestionnaire de fichiers locaux :
var store = localserver.createManagedStore(‘my_store’);
// On peut maintenant commencer les opérations sur le serveur local :
store.manifestUrl = ‘manifest.txt’ // On spécifie le "manifest" à utiliser.
store.checkForUpdate(); // Permet de vérifier les mises à jour des fichiers.
C’est pas bien sorcier hein ? Bon, les deux dernières lignes ne sont pas importantes, c’est juste pour vous montrer qu’il y a des méthodes et des attributs de disponibles.
Mais, concrètement, comment fonctionne le serveur local ? Comme je l’ai déjà dit plus haut, il s’agit avant tout d’un espace de stockage avec mise à jour des fichiers, rien de plus. Mais là où ça prend tout son intérêt c’est que, dorénavant, ce sont les fichiers enregistrés sur votre ordinateur qui seront chargés et non pas ceux disponibles sur Internet, c’est donc beaucoup plus rapide. Certains me diront que le cache fait ça tout aussi bien mais ce n’est pas vraiment le cas car Gears est quand même plus rapide et lui il peut enregistrer absolument tout et sans limite de temps, contrairement au cache de votre navigateur.
Venons-en maintenant au module Database, je vais faire court. Celui s’initialise de la même façon que le serveur local (en fait tous les modules s’initialisent de la même façon, c’est plus simple) et permet de créer plusieurs BDD pour un seul site web. La syntaxe d’écriture pour commander à la BDD reste très simple, on l’utilise à peu près de la même façon qu’une BDD classique.
Voilà, je ne pense pas qu’il soit nécessaire d’en dire plus.
Concernant le WorkerPool, je ne vais pas en parler vu que je n’ai pas vraiment étudié le truc.
Bref, tout ça c’est bien beau mais qu’est-ce qu’on pourrait bien faire d’utile et qui utilise Gears à bon escient ? Je me suis effectivement posé cette question moi aussi et en fait la réponse est simple : Gears n’a pas été conçu pour faire des sites webs disponibles hors-ligne mais pour créer des applications !
Des applications ? Oui ! Je pense que vous connaissez tous ce système d’éditeur de texte en ligne, il en existe plusieurs mais on ne peut y accéder que en ligne. Alors pourquoi ne pas le rendre compatible avec Google Gears ? Ainsi l’accès à l’éditeur se ferait depuis n’importe où, et ce, même sans connexion Internet.
On constate d’ailleurs que Google a commencé à exploiter son propre plugin, l’entreprise a déjà rendu plusieurs de ses applications compatibles avec Gears, on peut notamment citer : Gmail, Calendar, Youtube aussi ! Je crois qu’il y en a d’autres mais je ne les connais pas tous.
Bref, je crois avoir fait le tour sur ce plugin. Pour ceux qui voudraient éventuellement essayer, j’ai réalisé une petite page web exploitant le Localserver (pas de Database non, la flemme). Et pour ceux qui voudraient en voir plus alors je vous redirige vers le site de développement où on peut trouver quelques exemples.
Ah, dernière chose ! Si vous êtes tentés par l’aventure (autrement dit, si vous voulez coder pour Gears), ne vous étonnez pas de voir des bugs, Gears est encore en version bêta ! D’ailleurs si vous en trouvez un je vous recommande de le rapporter ici, j’en ai moi-même rapporté deux (ici et là).
Voilà tout, à la prochaine !
Nes’
Comment débugger un code Javascript
En ce moment je ne fous vraiment plus rien sur mes projets, en fait je n’ai tout simplement pas la motivation (et ça m’énerve parce que les idées arrivent en masse). Dès que j’essaye de me mettre à coder je perds toute envie et je pars jouer à TF2. Y’a des périodes comme ça… ça m’est déjà arrivé et ça arrive aussi à d’autres. Bref, en ce moment je suis en mode flemmard.
Donc, vu que je n’ai rien à vous raconter sur ce que je fais (je joue, ça vous intéresse pas trop je suppose ^^’ ), j’ai décidé de sortir un petit article sur comment débugger un code en Javascript parce que je vois souvent pas mal de gens sur le forum du SdZ qui disent que “ça ne marche pas”. Oui, c’est bien, mais un peu plus d’infos et de recherche ça serait mieux non ? Si j’avais appelé le SdZ à la rescousse pour chacun de mes problèmes, j’en serai encore à coder le prototype de Sliding Menu…
Il faut savoir être un minimum autonome les gens ! Plein de solutions existent pour debugger un code, et parmi elles se trouvent des moyens très simples. Voici les principales :
- La console de votre navigateur : Non, la console n’est pas là pour faire joli sur votre bureau de geek, elle sert réellement à quelque chose ! Si je prends Firefox pour exemple, la console liste les erreurs de style CSS rencontrées mais aussi les erreurs de syntaxe dans votre code JS. La première chose à faire quand votre code ne fonctionne pas c’est de jeter un coup d’oeil à la console (elle est généralement accessible sur tous les navigateurs dans le menu des outils ou bien en mode développeur).
- Utiliser la fonction alert() : Généralement, si on a rien dans la console et que le code ne fonctionne toujours pas, c’est à cause d’une valeur erronée. Quand je parle de valeur erronée, je veux désigner par là tout ce qui concerne les variables. Imaginons que vous ayez une variable permettant de spécifier la position d’un DIV mais que celui-ci ne soit finalement pas à l’endroit auquel vous vous attendiez. Est-ce qu’il s’agit alors d’une erreur de CSS ou bien d’une erreur de JS ? Pour vérifier cela il vous suffit alors d’afficher la valeur que vous avez attribué à la position de votre DIV à l’aide d’un alert() et vous serez très vite fixé car si c’est la bonne valeur, il s’agit alors d’une erreur de CSS, dans le cas contraire il s’agira très probablement d’un mauvais calcul pour cette valeur.
Le alert() est aussi très pratique pour vérifier si une condition s’est bien exécutée, il vous suffit de placer un alert() avec un message de votre choix dans la condition et si il est affiché alors la condition a bien été exécutée.
Toutefois, le alert() a un défaut en ce qui concerne la lecture de variables : il ne peut pas être utilisé dans une boucle qui se répète de trop nombreuses fois. Pour cela il y a une autre façon de faire décrite ci-dessous. - Afficher les valeurs directement dans le HTML : C’est “on ne peut plus bête”, il vous suffit de créer une balise de type SPAN (ou autre, au choix), de lui attribuer un id et d’y afficher les valeurs souhaitées. Simple, mais efficace. Généralement, j’utilise cette méthode quand je veux afficher le contenu d’une variable qui se trouve dans une boucle ou bien dans une fonction exécutée par un setInterval().
- Utiliser un debugger : Bon, cela est réservé à des besoins assez particuliers. Certaines personnes utilisent le debugger pour lire les valeurs de leurs variables pendant l’exécution du code mais je trouve ça parfaitement inutile, un bon vieux alert() est bien plus efficace ! En revanche, l’utilité d’un debugger se révèle lorsqu’il s’agit d’analyser du DHTML car si vous modifiez votre page web à l’aide du JS, le nouveau code HTML ne sera pas accessible, or le debugger, lui, sait afficher ce code modifié. Si vous souhaitez avoir un debugger sous Firefox, il vous faudra utiliser le plugin Firebug (perso, je préfère utiliser le debugger intégré à Chrome).
- Demander de l’aide sur un forum : Oui, je le mets en dernier car on demande de l’aide quand on ne trouve pas et non pas quand on a la flemme de chercher ! Mettez-vous bien ça dans le crâne : le forum c’est le dernier recours à utiliser !
Personnellement, quand j’aide sur un forum, je le fais pour quelqu’un qui a envie de progresser et non pas pour un type qui veut qu’on lui finisse son code alors qu’il se tourne les pouces.
Voilà pour ma petite liste qui, autant le dire, n’aura pas servi aux habitués du Javascript. En revanche, j’espère avoir aidé certaines personnes qui débutent à mieux comprendre comment trouver leurs erreurs. Certes, c’est pas toujours très simple de les trouver mais c’est tellement plus enrichissant de le faire soi-même =)
À noter que tout ce que j’ai écrit ne s’applique pas uniquement au Javascript mais aussi à beaucoup d’autres langages (même pour la programmation logicielle), il suffit juste de modifier les méthodes d’affichage.
Nes’
Speedbox, ça avance !
Avant de commencer, je profite de cet article pour vous souhaiter à tous une très bonne année, pleine de bonheur, etc…
Je ne sais pas pour vous mais j’ai deux résolutions pour l’année :
- Avoir mon Bac
- Me raser plus souvent \o/
Bien, on arrête les conneries (parce que dans un sens la nouvelle année ce n’est qu’une simple formalité hein… je déconne, tapez pas T_T ) et on passe au vif du sujet :
J’ai commencé, il y a quelques jours, à bosser sur Speedbox et il se trouve que ça se passe plutôt bien et que je ne rencontre pas trop de problèmes (pour le moment). Pour ceux qui ne savent pas de quoi je parle, je vous renvoie à cet article (à partir de la troisième image).
Pour le moment, j’ai codé les fonctions principales qui sont en gros : le chargement de l’image, le positionnement de tout le bardaf et enfin l’affichage de l’image. Les animations viendront plus tard.
J’ai aussi un peu revu mes priorités, avant je voulais pas mal bosser sur le design, mais comme je reste une loque dans ce domaine, il restera donc comme il est actuellement (en clair, pas terrible).
Par contre j’ai implémenté l’une des fonctionnalités principales : le redimensionnement des images quand celles-ci sont trop grandes. Alors faut pas trop rêver non plus, il s’agit d’un redimensionnement par le biais de balises HTML, rien de bien incroyable, mais au moins ça marche (même si c’est un peu gourmand en ressources).
Mieux encore ! Si vous redimensionnez la taille de votre fenêtre, le design se réorganisera automatiquement afin que la mise en page ne soit pas détruite !
Bref, après vous avoir gavé de tout ça, je vous invite à essayer et à me dire ce que vous en pensez. Pour le moment il n’y a que très peu de fonctionnalités implémentées donc j’aimerais que vous me donniez un avis sur ce qui existe et non pas sur ce que vous voudriez voir (on verra ça plus tard ^^ ).
Ah, aussi ! J’ai découvert deux bugs pour le moment, ça ne sera pas utile de les rapporter :
- Quand on réduit la taille d’une fenêtre sous IE, le fond ne s’ajuste pas correctement au niveau de la hauteur.
- Sous Opera, le fond opaque ajoute un blanc à la fin de la page.
Merci pour les éventuels commentaires,
Nes’