+ Répondre à la discussion Actualité déjà publiée
Page 8 sur 10 PremièrePremière ... 45678910 DernièreDernière
  1. #141
    Membre expérimenté Avatar de Willpower
    Homme Profil pro
    sans emploi
    Inscrit en
    décembre 2010
    Messages
    1 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : sans emploi

    Informations forums :
    Inscription : décembre 2010
    Messages : 1 009
    Points : 1 565
    Points
    1 565

    Par défaut

    Citation Envoyé par Bovino Voir le message
    Alors si je peux me permettre de recentrer un peu le débat, je rappelle que le titre de la discussion est


    Or les bonnes pratiques et les performances ne sont pas toujours en rapport, loin de là.
    A titre d'exemple, les bonnes pratiques demandent habituellement de placer les scripts dans la balise <head> du document, ceci afin de pouvoir respecter le principe de séparation des couches ((X)HTML pour le contenu, CSS pour la présentation et JavaScript pour le comportement), or la recherche de performances préconise plus de placer les scripts juste avant la fermeture du </body>.

    Du coup, pour répondre à

    je partage l'opinion de sekaijin : à mon sens, la bonne pratique est de stocker dans une variable les données utilisées plusieurs fois plutôt que de les rechercher plusieurs fois.
    C'est la même raison qui fait qu'il est préférable de stocker le length avant une boucle plutôt que de rechercher cette valeur à chaque itération.

    pour mon length, je trouve ça vraiment moche de rajouter une ligne de code pour les petits parcours (genre 3 iters)

    genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    var length = tableau.length;
    for(var i=0;i<length;i++)
      document.write(tableau[i]+"<br/>"); // c'est fait exprès parce que je sais que vous êtes allergiques au document.write ^.^
    plutot que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    for(var i=0;i<tableau.length;i++)
      document.write(tableau[i]+"<br/>");
    alors en général, je me contente d'un compromis entre les 2 quand le parcours n'a pas de "sens de traitement" imposé :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    for(var i=tableau.length-1;i>0;i--)
      document.write(tableau[i]+"<br/>");
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    eval(a='eval(a)')
    recursive make it evil
    eval make it eval


    Mes sites : gpt1 - codeeplus - instantw

  2. #142
    Rédacteur

    Avatar de Bovino
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2008
    Messages
    23 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2008
    Messages : 23 761
    Points : 92 059
    Points
    92 059
    Billets dans le blog
    20

    Par défaut

    Je suis d'accord avec toi, mais là il s'agit du pragmatisme dont parlait sekaijin

    Vouloir toujours appliquer les bonnes pratiques peut contribuer à alourdir inutilement le code.
    En revanche, connaitre les bonnes pratiques permet de choisir ses options au mieux.
    Pas de question technique par MP !
    Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi !
    Mes formations video2brain : La formation complète sur JavaScriptJavaScript et le DOM par la pratiquePHP 5 et MySQL : les fondamentaux
    Mon livre sur jQuery
    Module Firefox / Chrome d'intégration de JSFiddle et CodePen sur le forum

  3. #143
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 933
    Points : 8 229
    Points
    8 229

    Par défaut

    Citation Envoyé par marcha Voir le message
    Qu'entends-tu par bien plus efficace ? gagner 10 nano secondes toutes les
    secondes ? getElementById est optimisé aujourd'hui par les navigateur, c'est
    un non sens de chercher à économiser quelques cycles CPU au détriment de
    la simplicité d'écriture du code.
    heu c'est quoi le plus simple ??
    exemple on cherche l''élément à chaque click
    Code html : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    <script>myFonction(id) {
       el = document.getElementById(id);
       //fait quelque chose avec el
    }</script> 
    <a id="45" onclick="return myFonction(45)">click</a>
    le même
    Code html : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    <script>myFonction(el) {
       //fait quelque chose avec el
    }</script> 
    <a onclick="return myFonction(this)">click</a>

    lorsque tu a trois élément dans ta page pas de pb
    j'en ai parfois plusieurs dizaines de milliers
    et je peut affirmer que ça ce voit

    d'ailleurs beaucoup de lib on une fonction qui fait ça
    dès que tu cherche un éléments elle en place une référence dans un tableau au cas où pour le coup d'après.
    et ce n'est pas un hasard.

    quand à la simplicité du code c'est généralement beaucoup plus simple d'avoir une référence que de jongler avec les ids.

    mais là encore il faut être pragmatique.
    dans une page HTML avec un plugin Jquery pour saisir une date les ID c'est cool

    dans une application comme ce que fait madevilts ou comme moi toujours autour de 30 000 ligne de javascript auxquelles j'ajoute ExtJS les id c'est chronophage.

    il n'est donc pas question de les bannir mais de les utiliser à bon escient.

    quant à chercher à les supprimer c'est une vois d'optimisation dans les grosses applications. dans ce cas on gères des milliers voire des millions d'événement dans une session. et le travail de l'utilisateur en dépends. donc comme pour une application C++ un cycle d'horloge de moins X quelques millions d'événements par session X 100 000 utilisateurs X 300 Jours.

    ça représente du temps et ce temps il est payé pour travailler pas pour attendre que l'appli réagisse.

    c'est peut être con mais Oui on traque les milliscondes dans les entreprise.
    A+JYT

  4. #144
    Expert éminent
    Avatar de Auteur
    Profil pro
    Inscrit en
    avril 2004
    Messages
    6 584
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : avril 2004
    Messages : 6 584
    Points : 9 230
    Points
    9 230

    Par défaut

    Citation Envoyé par sekaijin Voir le message
    Pourquoi à chaque fois on ne se concentre que sur une partie du post des gens
    en omettant ce qui change tout son sens ?

    donc en toutes circonstances soyez pragmatique.
    C'est étonnant de voir que lorsque quelqu'un dit
    il a A
    ou il a B

    Les réaction sont

    et ceci mais cela

    Heu les gars un post c'est un tout
    Lisez le entier. et si vous en critiquez une partie n'oubliez de citer ce qui dans le reste dit exactement la même chose que votre critique.
    j'ai effectivement raté la fin de ton message sekaijin
    Et avec la dernière ligne ton message prend un tout autre sens. J'ai donc mal compris ta pensée. Encore désolé


  5. #145
    Membre actif
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    327
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : janvier 2007
    Messages : 327
    Points : 201
    Points
    201

    Par défaut

    Merci pour ton explication sekaijin
    trés bon topique j'apprends beaucoup de chose

  6. #146
    Membre à l'essai Avatar de sylvain230
    Homme Profil pro
    Orléans
    Inscrit en
    mai 2008
    Messages
    233
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Orléans
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 233
    Points : 21
    Points
    21

    Par défaut

    Est ce que vous pensez que c'est une bonne pratique d'intégrer la nouvelle API WebGL dans du Javascript ?
    Un jour quelqu'un a dit :
    Je ne savais pas qu'il fallait faire correctement ...

  7. #147
    Futur Membre du Club
    Profil pro
    Inscrit en
    février 2010
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2010
    Messages : 3
    Points : 6
    Points
    6

    Par défaut

    Le javascript ne possédant pas de "JIT compiler" à ce que je sais il faut trouver un bon équilibre entre garder une bonne structure pour pas que le flot de code gène sa conception et être le plus "verbose" possible ... ne pas hésiter à forcer des micro compilations comme "var length=tableau.length;" c'est un peu la base.

  8. #148
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 933
    Points : 8 229
    Points
    8 229

    Par défaut

    suivant les moteur JS JIT ou ce qui s'en approche est présent ou pas.

    le machine virtuelle JS moderne ont un fonctionnement qui à mon avis est très proche de JIT
    le source est chargé dans le buffer l'analyser lexical entre en oeuvre et détecte les éléments définis dans le script comme les var et les fonctions pour chaque nom que l'analyser syntaxique détecte il crée dans la VM la définition correspondante. si c'est une fonction seule la signature est créée est le source du corps lui est associé et elle est marquée non compilé.
    elle ne le sera que l'ors de la première utilisation.

    ce n'est pas JIT mais ça y ressemble furieusement.

    je ne sais pas si les vm comme celle IE9 ou le nouvelle version de JavaScriptCore (webkit) ne pousse pas jusqu'à faire l'analyse syntaxique sans faire la génération de code. je n'ai pas regardé le fonctionnement interne des moteur depuis longtemps. mais il me semble que IE9 stocke les chaînes de dépendance entre les fonctions et qui compile dans les temps mort certaines méthodes pour éviter les chaînes trop longues qui engendreraient des temps de compilation/exécution trop long.

    les stratégies des différents moteurs sont justement ce qui les différencient.
    A+JYT

  9. #149
    Membre éclairé
    Homme Profil pro
    F5(){F5}
    Inscrit en
    avril 2008
    Messages
    549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : F5(){F5}
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2008
    Messages : 549
    Points : 873
    Points
    873

    Par défaut

    Pour ma part, en plus de ce qui a déjà été dit :
    • Préférer au possible le passage d'objet en paramètres de fonction lorsque beaucoup d'arguments.
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
       
      function toto(obj){
       /*ie : obj=={name:'bob',firstName:'moran',...}; */
      }
    • Une seule "classe"=function à instancier avec new par fichier et nommer son fichier du même nom que la fonction avec la première lettre en majuscule.
      Cela facilite l'exploration du code quand on dev.
    • Les fonctions ne nécessitant pas instanciation ont justement la première lettre en minuscule.
    • Toujours des accollades {} autour des if/else. Ca a déjà été dit, mais je rajoute une raison (que j'ai pe ratée). Il s'agit de pouvoir facilement tracer le code en rajoutant une ligne dans le bloc (console.log par exemple). Donc c'est pas perdu.
    • Lors de la définition d'une fermeture, préférer la première syntaxe
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
       
      function Popper(objParams){
        var _private = objParams['specialProperty'];
        var that = {};
        that.kikoo = function(){
         return _private;
        };
        that.kikooUpper = function(){
          return that.kikoo().toUpperCase();
        };
        return that;
      }
      à la suivante
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
       
      function Popper(objParams){
        var _private = objParams['specialProperty'];
        var kikoo = function(){
          return _private;
        }
        return {
          kikoo:kikoo,
          kikooUpper:function(){
            return kikoo().toUpperCase();
          }
        };
      }
      Dans le premier cas, on a déjà moins d'indentation.
      En plus, les méthodes définies sur that sont déjà accessibles par celles qu'on définit par la suite.
      Dans la seconde, on est obligé de définir kikoo pour pouvoir l'appeler depuis kikooUpper, donc autant définir directement sur la variable that.
    • Egalement, préfixer les variables "privées" (non visibles par l'appelant) par un underscore.
    • Et un anti-pattern : on ne peut pas utiliser un nom de variable qui est un mot clé du langage. Donc par exemple
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
       
      function popper(class){
       //do some stuff on html nodes with 'class' attr
      }
      est incorrect.
      J'ai déjà vu du
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
       
      function popper(klass){
       //do some stuff on html nodes with 'class' attr
      }
      pour contourner le probleme. C'est mauvais car pertube l'esprit. Préférer className, ou quelquechose dans le genre.


    Voilà pour ma part.

  10. #150
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2010
    Messages
    18
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 18
    Points : 13
    Points
    13

    Par défaut

    Je réagis à un premier message où quelqu'un disait qu'il valait mieux éviter les innerHTML et leur préférer le DOM.

    Personnellement je trouve que le DOM implique une connaissance parfaite de l'architecture de la page, ce qui n'est pas forcément le cas. Je m'explique : je créé moi-même un gestionnaire de blog. Chaque blog contient des articles, qui sont récupérés en base via AJAX/PHP puis mis en forme et insérés. Donc chaque article récupéré rajoute un gros bout de code contenant toute sa mise en page, bouleversant ainsi le DOM de la page : dès lors il est très difficile de remonter/redescendre via les noeuds.

    Dans ce cas, rien de mieux que de bons vieux innerHTML sur des byId (dojo).

  11. #151
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 933
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 933
    Points : 8 229
    Points
    8 229

    Par défaut

    je ne vois pas en quoi
    un
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    document.getElementById('myId').innerHtml('ici du code source html avec des concaténation de chaine complexe pour insérer des ' + myVariable + ' le reste du Html en faisant attention que le code source soit conforme car il est facile d\'oublier de fermer une balide.')
    n'a rien de mieux que
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    document.getElementById(
      document.createElement('Div')
        .setAttribute('class', myVariable)
        .appendChild(document.createTextNode(
          'ici la variable s\'insère sans concaténation sans pb de syntaxe html'
        ))
    );
    bref que tu passe par innerHTML ou DOM ça ne change rien sur la page existante seul le fragment que tu définit passe par une interprétation de javascript qui passe ensuite par une interprétation d'une chaîne html généré pour donner un arbre DOM dans le cas d'Inner ou par l'interprétation de javascript pour donner un arbre DOM

    pour le reste pour l'arbre déjà existant ça ne change rien que tu passe par un parcours de l'arbre existant ou par un getElementById seul la façon don tu traite ton fragment change.

    A+JYT

  12. #152
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2007
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : février 2007
    Messages : 340
    Points : 350
    Points
    350

    Par défaut

    Au niveau des performances, qu'en pensez vous sur les nouveaux navigateurs ?

    Il y a 2 ans sur IE7 j'avais testé l'utilisation du DOM ou du innerHTML, sous IE7, l'utilisation du innerHTML était presque 2x plus rapide.

    Y a t'il des choses à éviter / ne pas faire ?

    Sur des RIA, il est difficile de mesurer la "lourdeur" du javascript sur les machines peu puissante.

  13. #153
    Rédacteur

    Avatar de Bovino
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2008
    Messages
    23 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2008
    Messages : 23 761
    Points : 92 059
    Points
    92 059
    Billets dans le blog
    20

    Par défaut

    Effectivement, pendant longtemps, la performance a été du coté d'innerHTML. Il me semble que sur les versions récentes des navigateurs, la tendance s'inverse.
    Ceci dit, innerHTML peut aussi poser des problèmes... pour IE
    Voir : http://www.developpez.net/forums/d97...l/#post5463783
    Pas de question technique par MP !
    Tout le monde peut participer à developpez.com, vous avez une idée, contactez-moi !
    Mes formations video2brain : La formation complète sur JavaScriptJavaScript et le DOM par la pratiquePHP 5 et MySQL : les fondamentaux
    Mon livre sur jQuery
    Module Firefox / Chrome d'intégration de JSFiddle et CodePen sur le forum

  14. #154
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    février 2007
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : février 2007
    Messages : 340
    Points : 350
    Points
    350

    Par défaut

    Ton exemple est très interessant néanmoins il me parait un peu paradoxale de faire une telle manoeuvre, à savoir : commencer par utiliser innerHTML puis continuer en DOM.

    Personnellement, autant que je peux j'utilise le DOM mais lorsque je souhaite remplir une popup avec du html reçu en ajax (par exemple), en un seul innerHTML, c'est souvent le plus pratique.

    Enfin, en clair, j'utilise soit l'un, soit l'autre mais jamais les 2 comme dans ton exemple.

    Pour ce qui est des performances, c'est assez étonnant. J'avais comparé entre IE7 et FF3, globalement FF3 est plus rapide mais sur certaines méthodes il était plus lent que IE. Je ne me souviens plus exactement mais sur la 1ere partie de mon code, IE était 20% + rapide que FF3, puis le renard reprenait l'avantage en lui collant +80% sur la génération du DOM.

  15. #155
    Membre émérite
    Avatar de Eric2a
    Homme Profil pro
    Inscrit en
    septembre 2005
    Messages
    1 225
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Corse (Corse)

    Informations forums :
    Inscription : septembre 2005
    Messages : 1 225
    Points : 2 336
    Points
    2 336

    Par défaut

    @Bovino
    Après la lecture du message d' ensareab j'ai de suite pensé au message que tu avais déposé dans le fil de discussion dont tu viens de placer le lien ici. Tant mieux parce que je ne le trouvais plus.
    @ensareab
    Avant je disais :
    "Moi j'aime utiliser le couple document.getElementById / innerHTML"
    Parce que c'est simple mais surtout parce que je n'avais pas envie de me prendre la tête avec DOM.

    Après avoir vérifié la démonstration de Bovino, je me suis mis modestement au DOM. Et maintenant je n'utilise innerHTML que dans de tès rares occasions.

  16. #156
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    540
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 540
    Points : 906
    Points
    906

    Par défaut

    Pour moi, la seule utilisation propre d'innerHTML, c'est pour vider entièrement un noeud...

    Dès qu'il s'agit d'ajouter du contenu -> DOM.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  17. #157
    Membre expérimenté Avatar de Willpower
    Homme Profil pro
    sans emploi
    Inscrit en
    décembre 2010
    Messages
    1 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : sans emploi

    Informations forums :
    Inscription : décembre 2010
    Messages : 1 009
    Points : 1 565
    Points
    1 565

    Par défaut

    Citation Envoyé par Bovino Voir le message
    Effectivement, pendant longtemps, la performance a été du coté d'innerHTML. Il me semble que sur les versions récentes des navigateurs, la tendance s'inverse.
    Ceci dit, innerHTML peut aussi poser des problèmes... pour IE
    Voir : http://www.developpez.net/forums/d97...l/#post5463783
    Le problème c'est que tu mélanges 2 façons de faire (bon ok, le vrai problème c'est IE mais soit).

    Tu crées un DIV en DOM.
    Tu l'injecte dans un autre DIV.
    Tu détruis le contenu de cet autre DIV grâce à innerHTML.
    Tu essayes de réinjecter ton premier DIV grâce au DOM.

    IE a donc détruit le contenu de ton autre DIV (et sa hiérarchie descendante) au lieu de les détacher simplement de ton autre DIV. Maintenant, je trouve ce comportement "presque" normal. Vu que innerHTML n'est pas une méthode de manipulation du DOM et n'est pas censé savoir qu'on garde des objets de type DOM en dehors de ceux attachés au document.

    Personnellement ton exemple ne me convainc pas d'exclure mes appels à "innerHTML" pour mes "petits" projets. Par contre, effectivement, j'éviterai les mélanges. (DOM et innerHTML).


    EDIT: je n'étais pas encore arrivé à la réponse de madevilts, on est apparemment sur la même longueur d'ondes.
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    eval(a='eval(a)')
    recursive make it evil
    eval make it eval


    Mes sites : gpt1 - codeeplus - instantw

  18. #158
    Membre expérimenté Avatar de Willpower
    Homme Profil pro
    sans emploi
    Inscrit en
    décembre 2010
    Messages
    1 009
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : sans emploi

    Informations forums :
    Inscription : décembre 2010
    Messages : 1 009
    Points : 1 565
    Points
    1 565

    Par défaut

    Citation Envoyé par Lcf.vs Voir le message
    Pour moi, la seule utilisation propre d'innerHTML, c'est pour vider entièrement un noeud...

    Dès qu'il s'agit d'ajouter du contenu -> DOM.


    C'est l'exemple que Bovino montrait comme "mauvais".
    Code javascript : Sélectionner tout - Visualiser dans une fenêtre à part
    eval(a='eval(a)')
    recursive make it evil
    eval make it eval


    Mes sites : gpt1 - codeeplus - instantw

  19. #159
    Membre éprouvé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    540
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 540
    Points : 906
    Points
    906

    Par défaut

    Ah, oui, tiens, un cas que je n'avais pas encore rencontré, pourtant, j'aurais dû m'en douter, pas la première "amnésie" d'IE que je remarque...

    L'ébauche de mon premier article y pointe un cas
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

  20. #160
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    mai 2010
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2010
    Messages : 86
    Points : 266
    Points
    266

    Par défaut

    Une intervention un peu tardive. ^^'
    J'ajoute de l'eau au moulin "pourquoi bannir eval() et dérivés" :

    Lorsqu'on utilise un minifier dans le process de release de l'environnement de développement vers l'environnement de prod, noms de fonctions et de variables sont remplacés par des raccourcis et tout le code est placé sur une ligne. Mais les chaînes de caractères, elles, ne sont évidemment pas remplacées. Aussi, imaginons le (sale) code suivant:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    function displayToto() {
        alert("toto");
    }
    setTimeout("displayToto()",300);
    En environnement de développement, tout se passera bien. Mais lors du déploiement vers la production, le minifier va passer par là, et ce code deviendra:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    function a(){alert("toto");}setTimeout("displayToto()",300);
    Avec comme résultat à l'exécution: "displayToto is not a function"...
    Et si vous faites la même chose avec une variable, ce sera un "maVariable is undefined"...
    Comme vous vous en doutez peut-être, je dis ça par expérience: il m'est arrivé de devoir intégrer dans mes apps du code fourni par des tiers, minifié évidemment, et de rencontrer ce genre d'erreur. La première fois que cela arrive, on se pose des questions, jusqu'à ce qu'on fasse une recherche sur la chaîne qui plante et qu'on la voie dans un setTimeout ou setInterval. -_-

    Note: je travaille fréquemment avec des régies publicitaires. Beaucoup d'entre elles n'ont pas de développeurs et se contentent de louer des adservers dans lesquels elles pluggent des tags d'autres régies (qui parfois renvoie vers des adservers d'encore autre régies, etc.). De plus, ces tags javascript sont généralement "optimisés" pour tenter de contourner les adblockers -_-' ("optimisations" faisant systématiquement appel à document.write() et eval(). -_-" ) Au final, l'éditeur d'application qui intègre les pubs dans ses produits se retrouve avec un monstrueux bout de javascript qui écrit des iframes, s'eval lui-même, et contient plusieurs imbrications du même tonneau... Sachez-le, beaucoup de saletés js et de crashs ne proviennent pas directement des développeurs qui codent l'app sur laquelle vous vous trouvez lorsqu'ils surviennent, mais des fichus espaces pub que leur marketing les force à intégrer.

    En terme de bonne pratique, je suis entièrement d'accord pour dire que le JS devrait toujours être placé dans des fichiers séparés et intégré avant la fermante de body d'une page.
    Mais quand on bosse sur une grosse application, particulièrement en .Net, pour une question de réutilisabilité du code, on réalise fréquemment des "contrôles" (pour ceux qui ne sauraient pas de quoi il s'agit, ce sont des fractions de code html + code behind + code js, un peu l'équivalent d'un widget, qui forment un objet que l'on peut instancier dans les objets pages).
    De plus, quand on reprend une appli qui a vécu, on doit faire avec ce qu'on a, et tout le monde ne se préoccupe pas de mettre son js là où il faudrait.
    Comme workaround afin de faciliter la maintenance, j'organise mon js comme suit:
    - la vue principale inclut un script externe définissant un objet js nommé selon l'application et contenant les variables globales, pour peu qu'elles soient vraiment obligatoires.
    - chaque bloc de code destiné à être rattaché à un contrôle se trouve dans un fichier séparé, et contient du code "objectisé" ajoutant une propriété nommée selon la fonctionnalité à l'objet de base de l'application. Ces propriétés sont bâties sur un modèle de closure (définies comme le retour d'une fonction anonyme qui va contenir des variables et des méthodes qui pourront être privées ou publique).
    - chacun de ces objets est paramétrable et possède une méthode "publique" init à laquelle passer un objet de settings.

    Par exemple: (tout est en anglais car je ne code que dans cette langue. Entreprise internationale ^^)
    fichier application.js:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    var Application = window.Application || { 
        iGlobal: 10,
        sGlobal: "blurp" 
    };
    fichier fonctionnality.js:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
     
    var Application = window.Application || {};
    var Application.Fonctionnality = (function(){
        //private var with default settings
        var _settings = {
            rootElement : element,
            booleanDummySetting : false
        }
     
        //dummy private method (not returned in the property)
        function dummyPrivate() {
            if(_settings.booleanDummySetting === true) {
                alert("blu");
        }
     
        //init method which will be public thanks to the return statement
        function init(obj) {
            //code here to merge the default settings with the option object
        }
     
        //return in which public methods have to be put in order to be public
        return {
            init:init
        }
    })();

Discussions similaires

  1. Bonnes pratiques pour la POO en Javascript
    Par piemur2000 dans le forum JavaScript
    Réponses: 5
    Dernier message: 05/10/2013, 15h33
  2. bonnes pratiques syntaxe javascript
    Par Invité dans le forum JavaScript
    Réponses: 2
    Dernier message: 27/06/2013, 10h40
  3. Bonnes pratiques de sécurité en JavaScript
    Par Toulousaing dans le forum JavaScript
    Réponses: 1
    Dernier message: 08/04/2012, 19h47
  4. javascript orienté objet: bonne pratique et héritage
    Par negstek dans le forum JavaScript
    Réponses: 9
    Dernier message: 31/08/2011, 19h27
  5. [POO] Bonnes pratiques href="javascript:fonction()"
    Par LhIaScZkTer dans le forum JavaScript
    Réponses: 20
    Dernier message: 04/04/2009, 18h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo