[Article] Javascript Orienté Objet : syntaxe de base des classes JavaScript à l'intention des développeurs PHP

Version imprimable

16/11/2010, 21h57
Bovino

[Article] Javascript Orienté Objet : syntaxe de base des classes JavaScript à l'intention des développeurs PHP

:salut:

Jean-Pierre Vincent vous propose un article de présentation sur la Programmation Orientée Objet en JavaScript.
:fleche: Javascript Orienté Objet : syntaxe de base des classes JavaScript à l'intention des développeurs PHP

Citation:

Ce tutoriel a pour cible les développeurs qui ont une expérience du PHP (5) et qui veulent se lancer dans un projet JavaScript qui dépasse le simple scripting. Cela va donc commencer par savoir écrire des classes en JavaScript. Pour avoir galéré en tant que développeur puis en tant que lead technique, avoir formé de bons développeurs PHP à faire des applications Web où le JavaScript représente plus d'un tiers du code et la moitié du temps de développement, j'ai pu constater les énervements classiques lorsqu'on commence à vouloir faire des choses sérieuses en JavaScript.
Le but ici n'est pas de rentrer dans la théorie du langage JavaScript ou même d'être exhaustif (voir à la fin de cet article des ressources qui le font très bien), mais de vous fournir un template pour commencer à écrire vos classes.

Merci de faire part de vos commentaires, remarques et encouragements pour cet article dont l'approche permettra, je l'espère, de faire comprendre que le modèle orienté objet par prototype est aussi valable que le modèle plus classique de classes et d'héritage.

Bonne lecture à tous et :merci: à l'auteur !

PS : Si vous souhaitez voter pour ce message, faites-le plutôt sur le message de jpvincent qui est l'auteur de l'article ;)
17/11/2010, 07h37
vermine

Article très intéressant. Bouts de codes à l'appui, ce qui permet de bien appréhender la transition du PhP vers le Javascript.
Merci pour cette démarche instructive. ;)
18/11/2010, 09h20
camus3

bon article , même si je déteste javascript. Non pas à cause du prototypage, mais parce que le développeur n'a pas le choix de la techno cliente finalement.
J'image ce qui aurait pu être le web si ruby ou python s'étaient imposé coté client. ECMA a fait un sale boulot, et il est trop tard pour changer quoi que ce soit , bref , les devs sont "coincés" avec javascript.
Néanmoins les closures et les lambdas sont l'aspect le plus puissant de javascript.
18/11/2010, 10h06
Bisûnûrs
Petite coquille dans le code PHP de la section "Classes statiques" :
Code:

1 2 3 static function isMailValid($sMail) { return (preg_match("/".self::$regMail."/", $sMail) === 1) ; }
Code:

print MY_APP_NAMESPACE\validation::isValidMail( 'mon@mail.com' );

De plus (mais ça n'entrave rien à la bonne marche de l'article), pour cette méthode on aurait pu utiliser filter_var() au lieu d'une expression régulière.
18/11/2010, 10h48
psychomatt

Merci pour cet article très intéressant.
Et j'en profite pour glisser que "oui je suis intéressé par la notion d'héritage en JS".
18/11/2010, 11h52
arcanis

Je pense que ça rentre dans le thème de l'article : j'ai fait il y a quelques temps un script permettant de gérer les classes Javascript en simulant le véritable concept des objets (public, protected, private, extends).

Ce n'est évidemment pas un script à utiliser en production (quoique si vous êtes un fanatique pur et dur ...), mais je le trouve assez intéressant en tant que proof of concept de ce qu'est capable d'accomplir le JS en matière d'objets.

http://arcanis.alwaysdata.net/classjs/class.js
http://arcanis.alwaysdata.net/classj...testsuite.html

Par ailleurs, en ce qui concerne les performances, un constat est réellement surprenant (et si quelqu'un découvre une erreur dans ma façon de compter, qu'il n'hésite pas, ça m'intéresse !) : il semblerait que, selon les navigateurs :
- IE 7 : Ne fonctionne pas, je n'ai pas cherché à le rendre compatible.
- Firefox : Environ 3x plus lent d'instancier un objet utilisant ma classe qu'un objet classique
- Chrome : Ca se vaut, avec un léger avantage pour un objet classique
- Opera : Donc là c'est le wtf : il est (semble-t-il) plus rapide d'instancier un objet de ma classe qu'un objet classique. Etrange, n'est-ce pas ?
18/11/2010, 11h54
grunk

Ca tombe pile au moment ou je dois développer une appli ou le JS sera dominant par rapport au reste !

Cela aurait pu être intéressant d'avoir un paragraphe sur les possibilité qu'apporte chaque framewok pour la réalisation de class.
18/11/2010, 12h28
jpvincent

Citation:

Envoyé par arcanis

- IE 7 : Ne fonctionne pas, je n'ai pas cherché à le rendre compatible.
- Firefox : Environ 3x plus lent d'instancier un objet utilisant ma classe qu'un objet classique
- Chrome : Ca se vaut, avec un léger avantage pour un objet classique
- Opera : Donc là c'est le wtf : il est (semble-t-il) plus rapide d'instancier un objet de ma classe qu'un objet classique. Etrange, n'est-ce pas ?

comportement bizarre effectivement
concernant chrome, j'ai souvent constaté que son comportement par rapport aux performances JS étaient radicalement différentes par rapport aux autres navigateurs : en général les IE et Firefox 3 sont d'accords pour préférer une méthode plutôt qu'une autre, alors que le V8 de Chrome affiche parfois des résultats inversés. Mais je pense de toute manière qu'il faut rester sur le plus petit dénominateur commun : IE6 ou 7. Si c'est optimisé pour ce navigateurs, ça n'est que rapide pour les autres

@grunk : ça aurait été intéressant, mais juger d'une librairie sur ce critère ne me semble pas très pertinent, car c'est une fonction mineure qui doit être supportée un peu partout de la même manière.
Juste une note sur les librairies : jQuery est très bien pour développer rapidement du scripting, rajouter des effets etc... Si tu pars sur une vraie appli Web, prend plutôt quelque chose de plus performant et solide, mais long à apprendre comme YUI3 ou Ext (payant)
18/11/2010, 20h12
Bovino
Citation:
Envoyé par Bisûnûrs

Petite coquille dans le code PHP de la section "Classes statiques" :

Code:

1 2 3 static function isMailValid($sMail) { return (preg_match("/".self::$regMail."/", $sMail) === 1) ; }

Code:

print MY_APP_NAMESPACE\validation::isValidMail( 'mon@mail.com' );

De plus (mais ça n'entrave rien à la bonne marche de l'article), pour cette méthode on aurait pu utiliser filter_var() au lieu d'une expression régulière.
Ca a été rectifié.

:merci:
19/11/2010, 01h39
kimjoa
très bonne articles !!

Il y a là toutes les bonnes techniques à adopter en js.... espace de nom, créer des variables local "ou privé", via des fonctions anonymes auto-exécuté...

C'est très bien :ccool::ccool: :aie:

Des petites remarque quand même !!

Sur la sections des closures et variables privée.
Etant dans un context POO, votre exemple est pas vraiment valable, car il retourne un objet anonyme, et non rattaché à une classe.
Pour permettre des variables privé d'instance, il suffit de redéfinir les méthodes dans le constructeur.

du genre:
Code:

1 2 3 4 5 6 7 function MaClasse(){ var argPrivé = "ok"; this.funtionPublic = function(){ return argPrivé; } }
Mais c'est à éviter , comme vous l'avez précisé...

Sinon je trouve pas le lien -> contre performance des variables privées

Je suis façe à un léger problème de portée de variable.

Soit l'extrait de classe suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
boxCmd : function() {
            $.post('index.php?mod=video&act=ajax_boxCmd',
            {csrf_protect:this.token},
            function(responseText) {
                $('#contenu_bas').append(responseText);
            });
        },
 
        ongletPilotage : function() {
            $.post('index.php?mod=video&act=ajax_pilotage',
            {csrf_protect:this.token},
            function(responseText) {
                $('#contenu_bas').append(responseText);
                this.boxCmd()
            });
        }

Dans la fonction de callback de ongletPilotage je souhaite appeller une méthode de ma classe. Seulement dans le contexte , this ne réfère plus à la classe mais à l'environnement de callback (je suppose).

J'ai dans un premier temps penser à modifier ma classe comme ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
ongletPilotage : function() {
            $.post('index.php?mod=video&act=ajax_pilotage',
            {csrf_protect:this.token},
            this.callbackPilotage);
        },
 
        callbackPilotage : function(responseText) {
            $('#contenu_bas').html(responseText);
            this.boxCmd();
        },

Mais ca ne marche pas mieux (Object has no method boxCmd).
Des idées pour solutionner cela ?

Enregistre this dans une closure.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
function Test() {}
 
Test.prototype.toto = function () {
    var self = this;
    $.get('foobar.php', function () {
        self.success();
    });
};
 
Test.prototype.success = function () {
    alert(this);
};

la réponse d'Arcanis est valable
sinon, en JS normal (oui, sans jQuery!), on peut appeller une méthode en lui donnant le scope
exemple
Code:

1 2 3 4 5 6 7 8 9 10 11 myObject = function() { this.myVariable = 1; }; var instance = new myObject(); function myFunction() { alert(this.myVariable); } myFunction(); // undefined myFunction.call(instance); // 1
Dans YUI, on peut donner le scope que l'on veut aux callbacks, fouille la doc jQuery pour voir si cette fonctionalité est prévue (probablement que oui, mais pas avec cette syntaxe)
Sinon oui par défaut le browser donne le scope de l'objet DOM d'où provient l'évènement

03/12/2010, 09h44
grunk

Merci à vous deux pour vos réponses.

La solution d'arcanis , marche parfaitement.

@jpvincent
De mémoire prototype permettait également de passer l'instance à une fonction de callback , je vais regarder du coté de jquery , pas de raison que ce soit pas possible.

Le soucis de call et d'apply, c'est que tu ne peux pas vraiment les utiliser pour des callbacks, sauf en rajoutant un peu de code pour englober les appels.

Au pire suffit de prototyper le code de Function :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Seul ce passage est réellement intéressant, le reste c'est une demo
Function.prototype.bind = function (context) {
    var func = this;
    return function () {
        func.apply(context, arguments);
    };
};
 
// Classe de test
function Foobar() {}
Foobar.prototype.tagazok = 42;
var scope = new Foobar();
 
// On construit une fonction et on lui force un scope défini
// A noter qu'en procédant ainsi, il ne sera pas possible de redéfinir le scope plus tard.
// Mais dans le cas des callbacks, généralement, on s'en fout.
var toto = function () { alert(this.tagazok); }
var scopedToto = toto.bind(scope);
 
setTimeout(toto, 1); // Fail
setTimeout(scopedToto, 1); // Pas fail

01/04/2011, 20h58
Etn3000

Salut,
Merci pour cet article très intéressant, je suis moi même dans les difficultés de l'apprentissage du JS après le PHP... ça va m'aider ;)
@+