Reprise du message précédent :
Je dois réaliser une classe en JS (sans le framework prototype).
 
C'est quoi le meilleur moyen de le faire (tant au niveau lisibilité que perfs).
 

function Foo() {}
Foo.prototype.bar = function() {}

function Foo() {}
Foo.prototype.bar = function() {}

Ca c'est rapide si tu instancie plusieurs objets, mais par facilite ou parce que tu veux un singleton tu peux aussi faire:

var Foo = function()
{
this.bar = function(){};

}

et

var Foo =
{
bar : function(){}
}

voire, pour séparer public/prive

(
var privateBar = function(){};
var publicBar = function()
{
privateBar ();
};

var Foo = {};
Foo.bar = publicBar;

return Foo;
)()

function Foo() {}
Foo.prototype.bar = function() {}

Niveau lisibilité y'a pas grand chose de mieux que ce que t'as écris. Sauf que tu peux faire

Foo.prototype = {'bar': function(){}};

La méthode de gelatine_velue à l'avantage d'avoir un pseudo concept de visibilité, en plus tu gagnes des fonctions traçables dans la call stack.
 
Sinon la bible:
 
http://www.youtube.com/watch?v=DwY [...] ature=plcp
 
et  
 
http://www.youtube.com/user/yuilib [...] ry=douglas

'tain
 
 
 

function Foo() {}
Foo.prototype.bar = function() {}

Bah soit ça, même si c'est verbeux (un peu pour la définition, beaucoup pour les appels à "super()" ), soit tu récupères le snippet de Resig qui te donne du sucre par dessus (sucre pas nécessairement tout le temps fiable par contre) ou tu utilises Classy (même chose mais avec des noms différents et un peu plus d'utilitaires), ou bien si tu te fous d'IE < 9 tu vas "full-prototype-ish" et tu utilises Object.create (notes que tu gagnes rien au niveau des "super" avec ça, par contre t'as accès aux properties et autres)

Hrm application cache me fait chier même après avoir lu "Application Cache is a Douchebag" et dive5: Offline
 

• Si une resource est spécifiée explicitement dans NETWORK, son FALLBACK sera récupéré mais pas utilisé
• "*" dans NETWORK, par contre, c'est bon
• une resource dans FALLBACK est automatiquement inclue dans les trucs dispos pour NETWORK
• une resource ni dans FALLBACK ni dans NETWORK ni dans CACHE:
•    Va être fetchée par FF si online
•    Va être ignorée par les navigateurs webkit (status 0), sauf (potentiellement) si elle est fetchée juste avant le premier chargement du manifeste, avant que webkit se rende compte qu'en fait il veut pas la fetcher

 
Et le validateur dit pas un mot
 
edit: et ça a l'air d'être un bug de firefox:

 
Justement, je ne veux pas de singleton, il me faut plusieurs instance de l'objet sur la même page.
Actuellement j'utilisais le module pattern, qui fonctionnait très bien jusqu'à ce que j'ai à l'utiliser 2 fois de suite : le second appel écrasait toutes les variables du premier.
 
Il faudrait que j'étudie de plus près le fonctionnement des plugins jQuery car tu peux avoir plusieurs "instances" du plugin sur la même page sans qu'il n'y ait aucun problèmes.
 

Foo.prototype = {'bar': function(){}};

 
C'est dommage que l'on ne puisse pas inclure les prototype dans la fonction de construction.
Niveau esthétique je trouve ça moche.
 

 
C'est vraiment pour un besoin ponctuel donc je vais éviter Classy qui rajoute encore une couche, pareil pour le snippet de Resig.

Quid de celui là ? Je le trouve sexy : http://stackoverflow.com/a/3913174/742980 mais pas de visibilité.

1. Je dirais osef de la visibilité (mais tu l'as avec ce truc, suffit de pas mettre les fonctions sur le this)
2. Ça correspond au truc "singleton" de gélatine, et c'est problèmatique parce que les méthodes sont pas partagées entre les instances (elles sont dupliquées, il recrée son set de 0 à chaque fois). Et ça me semble pas spécialement sexy.
 
À la limite, si tu veux un truc simple tu utilises un petit wrapper sur Function + prototype, genre la version avec encore moins de fonctionnalités de Classy/ResigClass

function Class(init, parent, methods) {
    var prototype;
    if (!parent) {
        prototype = {};
    } else {
        var ParentInit = function () {};
        ParentInit.prototype = parent.prototype;
        prototype = new ParentInit;
    }
 
    for(var name in methods) {
        prototype[name] = methods[name];
    }
 
    if (!init) { init = function () {}; }
    init.prototype = prototype;
    return init;
}

http://jsfiddle.net/V8vRP/
 
(ça pourrait probablement être amélioré pour que les paramètres soient optionnels, mais bon).

Donc autant rester sur du bon vieux prototype.

cf edit, tu peux faire du mini-sucre dessus pour que ce soit un peu moins chiant (surtout en cas d'héritage)

Avec mon ancienne implémentation (module pattern), dans une des méthodes je passais un callback "addAction" à une fonction comme ci-dessous :

this.grid.parse(this.json, addActions, "json" );

Maintenant avec l'implémentation prototype je suis obligé de faire ça ?

var that = this;
this.grid.parse(this.json, function() { that.addActions() }, "json" );

function Class(init, parent, methods) {
    var prototype;
    if (!parent) {
        prototype = {};
    } else {
        var ParentInit = function () {};
        ParentInit.prototype = parent.prototype;
        prototype = new ParentInit;
    }
 
    for(var name in methods) {
        prototype[name] = methods[name];
    }
 
    if (!init) { init = function () {}; }
    init.prototype = prototype;
    return init;
}

En quoi c'est plus simple que de passer directement par Prototype ?

Pas d'héritage à priori.

this.grid.parse(this.json, addActions, "json" );

var that = this;
this.grid.parse(this.json, function() { that.addActions() }, "json" );

Ou d'utiliser une quelconque forme de bind (Function#bind, _.bind, $.proxy)

Passer par Prototype ou passer par un prototype "brut"?

C'est juste plus simple à appeler, et ça gère l'héritage correctement (c'est la partie la plus chiante verbeuse avec prototypes bruts). Si tu fais pas d'héritage tu gagnes peu ou prou rien (sauf à améliorer encore un peu l'implémentation pour que Foo() et new Foo() fassent la même chose)

Ok, merci pour les précisions

Putain pour gérer correctement l'initialisation d'une offline web application, j'ai l'impression qu'il faut potentiellement se brancher sur 3 évènements différents sans compter DOMContentLoaded

j'ai une différence de 90px entre Chrome/FF et IE avec un .offset().top()
 
IE renvoi la bonne valeur (251px) alors que Chrome/FF renvoient 171px... vous sauriez d'où ça vient ? comment il fait son calcul jQuery ?

Un problème avec le padding / margin de l'élément ?

l'élement en cours n'a aucun margin ni padding  
 
edit: pb d'évenementiel.. ça marche sur le load() mais pas sur le ready()

L'ascenseur pris en compte/taille differente selon le navigateur?

Bah si tu as des images avant ton élément c'est évident que sur le ready ça merdera, apres que ca marche sous IE et pas sous chrome/ff, je dirais que c'est à cause du cache

alors le webservice KML du client rame à mort, donc je mets un cloudfront devant puis j'envoie son url à google maps pour faire le rendering

edit: en fait leur KML est invalide, il faut que je corrige à la volée

En HTML, y'a moyen de transmettre (ancre, formulaire, autre moyen que je vois pas) un GET en forçant le content-type ?
 
Si non, j'imagine que la seule solution est de passer un paramètre à la requête ?

le content-type de ce que tu envoies ou le content-type de ce que tu vas recevoir ?

edit : de souvenir : tu peux faire avec un lien : <a href="fichier.mid" type="audio/midi">fichier midi</a>

Mais le meilleur moyen est de forcer le content-type via serveur

 
De ce que je vais recevoir
Et après vérification, c'est bien "type" qui est utilisé, même si évidemment c'est le serveur qui aura le dessus sur cette décision.
 
D'accord avec ta remarque sur l'option serveur, mais j'aimerais réagir différemment à une même URL selon la demande, en jouant justement sur le content-type. "Type" est là pour ça, merci    
 

Est-ce que vous connaissez un moyen relativement automatisé de détecter le code mort dans une CSS ?
(des déclarations pour des classes qu'on ne trouve plus dans un set de fichiers par exemple)

sans l'integralité du code associé (html/js) c'est difficile.
si en plus tu as des media queries et des traitements liés a des specificités d'affichage (hack ie par ex) c'est encore plus l'echec.
 
par contre pour avoir une idée globale tu peux concatener l'integralité des templates et le passer sous pagespeed pour identifier les classes non utilisées par ff ou chrome.
apres tu sors le reste dans un fichier externe et tu reintegre si necessaire.

CSS usage ? plugin firefox, sinon très difficile, car il faut que le navigateur tourne. Donc pour automatiser tout ça, il est peut etre possible d'utiliser des navigateurs headless comme phantomJS

 
CSS Usage convient, merci beaucoup

http://vanilla-js.com/

vous testez comment vos applis web ?
genre selenium c'est super-lent et chiant à développer (tout à coup de timeout).
 
vous avez des trucs mieux, ou des moyens de l'utiliser de manière plus efficace ?

 
Ici c'est Selenium via Selenium IDE, la prise en main est chiante et il faut jouer avec les timeouts mais une fois que t'as pris le truc c'est pas si long que ça.
Le soucis c'est que justement c'est pas rapide à exécuter (enfin ça peut aller très vite mais les tests passaient jamais), mais après j'avais cru comprendre que vous aviez un serveur d'intégration.

ouais, mais là nos pauvres tests passent déjà en 14min, alors du coup quand on va en rajouter ça va commencer à sentir la morue.
 
Pour parallèliser c'est un peu la merde, parce qu'il faut autant d'instance serveur de l'appli que d'instances de selenium (les tests sont stateful), et le déploiement est assez lourd en charge.
 
j'arrive pas à trouver un point de déverrouillage du pb.

 
Dans un ancien projet où on utilisait selenium on avait pas trouvé non plus. Par contre nos tests duraient plutot une heure ou deux, du coup on laissait une machine les faire dans un coin.

On utilise Cucumber-js + CasperJS

- y'a encore un quelconque intérêt à servir du contenu en XHTML 1.0 Transitional ?
- ça peut être balancé à la poubelle pour un simple <!doctype html> sans trop d'effets secondaires ?

 
- y en a déjà eu ?
- oui

Et autre question so 2002, type="text/javascript" est complètement useless ou bien IE en a encore besoin dans du js embedded ?

 
Il est complètement useless, tu peux t'en passer, même pour IE6. Les tags <script> suffisent.

Ca fait longtemps que je ne l'utilise plus.

Thanks. C'est la première fois que j'interviens sur un code legacy sur lequel j'ai un peu de contrôle et que j'ai moyen de pouvoir moderniser un peu, donc y'a certaines questions existentielles que je ne m'étais jamais posées.
 
(sur d'autres missions, je laissais en état, et le reste du temps c'était du tout neuf, donc je savais que j'avais pas besoin de m'emmerder)

Bonjour, j'ai un problème et je sais pas si c'est exactement la bonne catégorie
 
J'essaie de développer un script Greasemonkey pour Firefox, et pour une raison qui m'est inconnue, les erreurs Javascript que je fais ne sont pas logguées dans la console web de Firefox. Autant j'ai les erreurs de tous les scripts JS de la page en cours d'exécution, autant celles de GM, niet.
 
Vous conviendrez que c'est un problème terriblement ennuyeux, et surtout je suis persuadé que ça marchait bien la dernière fois que j'ai touché à du GM (c'est à dire il y a 3 mois maxi)
 
Une idée d'où ça peut venir ?
 
EDIT:
 

 
Erreur bien référencée dans la console Firefox
 

 
Erreur non référencée dans la console Firefox