[OpenSource][Javascript]bibliothèque de Liaison de données

Version imprimable

14/02/2016, 14h17
st3ff

[OpenSource][Javascript]bibliothèque de Liaison de données

Bonjour,
Je me présente, Stéphane, développeur amateur, j'ai quelques connaissances en Java (pour Android), en CSharp/XAML, mais je code principalement en Python des petits outils et scripts.
Pour les besoins d'un logiciel afin de gérer mes contrats d'interim, je me suis tourné vers HTML5/CSS3/Javascript, parce que c'est ce qui me semblait le mieux et aussi par curiosité. Après quelques essais, j'ai commencé à rechercher des bibliothèques pour me simplifier la vie, et principalement, pour le data-binding (en fait, je trouvais que les "getElementById" prenaient un peu trop de place dans mon code…).
JQuery: UI, organisation, j'ai beaucoup aimé, mais niveau code, $("mon_id") ou getElementById, ça ne réglais pas le problème
AngularJS: j’ai rien compris à cette bibliothèque… Elle doit faire des trucs formidables, mais j'ai rien compris...
Knockout: plus évidente, mais trop de code javascript en plus, et puis un seul binding par élément ?!
Comme amateur (donc pas de limite de temps et envie de connaître mieux javascript) je me suis fait ma propre lib: fear the walking web:
déclarative: les bindings se déclarent dans le code HTML, ainsi que les presenters/templates pour l'affichage des objets/tableaux
multi binding :chaque attribut/propriété d'un tag HTML/objet HTMLElement peut recevoir un binding, et on peut en mettre plusieurs par élément HTML.
limite la modification des codes métiers: On doit juste créer un contexte de données (un objet javascript normal).

téléchargement: fear-the-walking-web

Description de l'archive:
ftw2.7z > fear-the-walking-web-flesh-and-bones.js: le fichier javascript à inclure dans votre page HTML.
ftw2.7z > docs > FearthewalkingwebDocsDemos.pdf: documentation + un exemple d'utilisation dans une application complète.
ftw2.7z > docs > exemples: les exemples de la documentation
ftw2.7z > docs > wows:l'application développée dans la documentation pour visualiser les cours de bourse d'une action.

ftw2.7z > pandemie: après avoir montré mon code à un ami, il m'a demandé si je comptais en faire un plugin JQuery. D'après ce que j'en ai compris, JQuery simplifie la manipulation du DOM, et ils ont construit un framework dessus (avec plein d'autres choses, ok…), alors que FTW2 permet au développeur de ne plus manipuler le DOM.
Comme amateur (donc le temps de prendre des décisions débiles), j'en suis arrivé à la conclusion qu'il serait plus logique(?!) de créer un framework complet basé sur le data binding! Ce n'est pour l'instant que quelques idées sur le fonctionnement, rien de bien concret encore.

Je suis très content de faire ma première release (comme disent les pros), actuellement en version 0.3, et de la poster sur DVP, (depuis le temps que je fréquente ce forum, enfin je peux lui rendre quelque chose!)

TODO:
améliorer les requêtes XPATH: souvent (toujours?) les bindings ne fonctionnent pas simplement parce que le xpath est mal fait (les caractères spéciaux dans les fallbacks par exemple)
optimiser le code: en temps d'exécution et en consommation mémoire
quelques fonctionnalités en plus auxquelles j'ai pensé en écrivant la documentation (binding direct sur webservice…)

que pensez vous de son utilisation?
que pensez vous de la documentation? Est elle assez claire?

Merci à tous pour le temps passé à essayer mon bout de code et pour vos retours.
14/02/2016, 15h11
fozzeuh

Salut, ça serait cool si au lieu de télécharger tes fichiers on pouvait les voirs sur github.

Cordialement,
15/02/2016, 07h49
st3ff

euh, oui, je vais voir comment faire ça ce soir. Merci
Bon, je suis officiellement en retard au travail, mais c'était moins compliqué que je pensais: github.com fear-the-walking-web
18/02/2016, 13h59
st3ff

Bonjour, juste une petite mise à jour après m’être aperçu que l'application d'exemple bug avec le navigateur EDGE. Pour infos, les éléments SVG avec EDGE n'ont pas de propriété "children", uniquement le "childNodes" renvoyant tous les nodes enfants (dont les EmptyTextElement). Opera, Chrome, Firefox n'ont pas se problème.
Merci
19/02/2016, 16h15
st3ff

Bonjour,
après une lecture très intéressante sur les closures en javascript, j'ai modifié le code de façon à ne plus créer de fonctions dans des fonctions (pour avoir accès à des variables), gérer un peu mieux les prototypes, faire un peu le ménage dans les propriétés des objets... Je trouve ça plus clair du coup!
Demain, je m'attaque aux XPATH...
23/02/2016, 11h28
st3ff

Bonjour,
Encore un petit commit sur github (version 0.5) pour permettre de passer à un binding une url d'un service web, et lui fournir des paramètres. J'ai mis a jour la doc (ça se trouve a la fin de la partie sur le binding d'objet) et ajouter un exemple (docs/exemples/webservice.html) pour montrer comment on s'en sert.
Dès que j'ai le temps, je referais l'application d'exemple (wows) en utilisant ce type de binding.
Merci
25/02/2016, 11h41
st3ff

Bonjour,
une nouvelle mise a jour pour Fear the walking web! (sur github). Dans cette nouvelle version:
- principalement du debug: je me suis assuré que tous les exemples fonctionnent bien! J'ai encore un problème avec le binding $this il me semble...
- compatibilité: j'ai testé les exemples et l'application WoWS sous chrome/firefox/opera et edge et fait les adaptations nécessaires, tout semble marcher maintenant.
- quelques optimisations: mises en cache des éléments HTML, utilisation des fragments des que possible
- "docs/exemples/2way.html": j'avais oublié de préciser "forceAttr:true" dans le binding de style pour le bouton submit, Edge n'aimait pas

Maintenant, je commence a me tourner vers les outils de profilage (de chrome et firefox) pour détecter les bottlenecks et les fuites de mémoires. Tant que j'y suis, si quelqu'un connaît un bon tutorial sur comment utiliser ces outils, je suis preneur...
25/02/2016, 21h14
SylvainPV

Hello,

Comme promis voilà mes retours. Tout d'abord ça serait cool d'avoir la doc en texte plutôt qu'en PDF. Ne pas pouvoir copier/coller les exemples, c'est cruel !

Le premier truc qui m'a instantanément gêné c'est toutes ces variables globales que déclare la lib. Si une seule d'entre elles est surchargé par un script utilisateur, c'est foutu, la lib est cassée ! Inversement tu peux casser une autre lib s'il y a des conflits de globales. Il faut impérativement mettre le code de ta lib dans une IIFE pour n'exposer que le strict minimum (1 variable globale, voire pas du tout). De même, la lib impose que que l'objet de contexte soit dans la portée globale et ça, c'est inacceptable pour beaucoup de développeurs JS. Ça fait plusieurs années que je maintiens une politique zéro globale pour mes projets professionnels. On a déjà eu des clients avec des extensions navigateur bien sales qui surchargeaient les globales des sites web consultés. Dans le meilleur des cas, ça cassait le fonctionnement des sites. Dans le pire des cas, ça se servait allègrement dans les données transitées et ça envoyait le tout en AJAX vers des serveurs assez louches. Bref, le seul moyen de se protéger contre ça, c'est de ne pas exposer de variables globales.

Je vois aussi que la lib surcharge des fonctions natives du navigateur comme Object.defineProperty ou HTMLElement.prototype.addEventListener et c'est une très mauvaise pratique selon moi. Plein de libs utilisent Object.defineProperty et addEventListener, et elles vont toutes interférer avec ta lib. Je pense que ça peut causer de très gros dégâts et je ne vois pas l'intérêt de surcharger ces fonctions plutôt que d'utiliser un wrapper.

Du reste, on sent que c'est une version 0.3 et il manque des choses de base comme une séparation du code en plusieurs fichiers pour plus de lisibilité, une version minifiée et UMD de la lib, un README, un choix de license etc.. J'imagine que tu prévois tout ça pour les prochaines versions. Mais je te recommande de préparer dès le départ une bonne base si tu veux partager ton projet en open source ; c'est-à-dire une bonne décomposition des sources, un process de build pour concaténer/minifier le tout, et idéalement des tests unitaires pour prévenir les régressions.

Voilà c'est que des retours sur la technique car sur le principe de la lib tu as pu voir que j'étais tout à fait dans le même esprit ;) FTW2 et Databinder ont grosso modo les mêmes features, même si l'API est assez différente.

Bon courage pour la suite :ccool:
25/02/2016, 23h35
st3ff

Merci pour toutes tes remarques.

Citation:

Envoyé par SylvainPV

Tout d'abord ça serait cool d'avoir la doc en texte plutôt qu'en PDF. Ne pas pouvoir copier/coller les exemples, c'est cruel !

j'y avais pas pensé, les fichiers d'exemples me semblaient suffisant.

Citation:

Envoyé par SylvainPV

Le premier truc qui m'a instantanément gêné c'est toutes ces variables globales que déclare la lib.

tu me conseillerais quoi? Créer un objet pour les stocker? J'avoue être allé au plus simple parfois (souvent), et ce genre de remarques est exactement ce que je recherche.

Citation:

Envoyé par SylvainPV

Il faut impérativement mettre le code de ta lib dans une IIFE

Je comprends pas IIFE, ça veut dire quoi exactement?

Citation:

Envoyé par SylvainPV

je ne vois pas l'intérêt de surcharger ces fonctions plutôt que d'utiliser un wrapper.

En fait, j'ai adapté la lib à ma façon de coder (pour le defineProperty), ce qui m'évitait de créer un objet context de base à surcharger et de pouvoir récupérer des anciens codes sans avoir a le modifier. Pour les eventListeners, c'est plus une façon pour ne pas oublier les nettoyages, mais ça peut se changer sans problème

Citation:

Envoyé par SylvainPV

une version minifiée et UMD de la lib

pareil, excuse moi, mais UMD, ça veut dire quoi?

Citation:

Envoyé par SylvainPV

Mais je te recommande de préparer dès le départ une bonne base

C'est pour ça que je suis là!

IIFE = Immediately Invoked Function Expression
https://en.wikipedia.org/wiki/Immedi...ion_expression

C'est le moyen le plus simple pour isoler des variables de la portée globale.

UMD = Universal Module Definition
http://davidbcalhoun.com/2014/what-i...monjs-and-umd/

C'est un autre pattern pour rendre compatible ta lib avec les module loaders de type CommonJS ou AMD ; cela permet d'importer ta lib sans avoir besoin d'aucune variable globale. Généralement on fournit une version minifiée et une version UMD selon la manière dont l'utilisateur consomme la lib.

En gros ça se résume à ça:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 (function (globals, factory) { if (typeof define === 'function' && define.amd) define(factory); // AMD else if (typeof exports === 'object') module.exports = factory(); // Node else globals['TA_VARIABLE_GLOBALE'] = factory(); // globals }(this, function () { // le code de ta lib return TON_NAMESPACE_PRINCIPAL }));
exemple avec une autre de mes lib: https://github.com/sylvainpolletvill...t-model.umd.js

Tu remarqueras que le pattern UMD fournit justement une IIFE

26/02/2016, 09h33
st3ff

Bonjour,
merci pour les renseignements. Si je comprends bien, ces patterns (ça me fait bizarre de voir "design pattern" et javascript dans la même phrase, je pensais pas. Bon… moins que 'memory leak' et javascript, mais quand même) permettent de créer des "modules' ou 'namespace' dans le code. J'avais déjà vu écrit des trucs comme ça, mais j'avais royalement ignoré en me disant qu'ils se prenaient la tête pour rien (finalement, une fois expliqué, pas tant que ça).
Je me demande si on peut définir des modules (faute de trouver un autre nom) à l'intérieur d'un autre. Je me vois bien reprendre une architecture type packages pour me faciliter la vie (parce que tout dans un même fichier, on est d'accord, c'est lourd), et automatiser le process avec un petit script python (rajouter des directives dans les fichiers js au début, du style @require un_fichier pour le load order, une autre @public/private dans le commentaire des fonctions/objets pour savoir quoi exporter, faire passer un minifier style YUI compressor, rajouter l'entête et voila!, le tout s'exécutant a chaque fois qu'il y a une sauvegarde dans le dossier…)
Bon, ben y'a plus qu'a…

Au fait merci pour la vidéo, c'était particulièrement intéressant! Ils ont pleins de vidéos sur youtube, ça va m'occuper les soirées je sens.
26/02/2016, 10h45
SylvainPV

Les modules font partie officiellement de JavaScript depuis la norme ES6: https://developer.mozilla.org/fr/doc...uctions/import

Une fois qu'ils seront supportés nativement par la plupart des navigateurs, UMD deviendra obsolète.

Tu peux utiliser cette syntaxe puis utiliser un transpilateur qui vienne convertir ça en notation UMD ou en bundle minifié : http://babeljs.io/docs/plugins/trans...5-modules-umd/

Ou alors tu peux écrire ton propre script avec ta propre syntaxe, comme tu veux. Perso je n'utilise pas Python mais des tasks runners JS comme Grunt ou Gulp pour ça, voilà mon setup pour Databinder: https://github.com/sylvainpolletvill...r/Gruntfile.js ; ils sont très utilisés pour faire toutes les tâches que tu as mentionné (modules, minification, watcher etc...)

Salut, excuse moi de t'ennuyer encore, mais il y quelque chose que je ne comprends pas avec UMD. J'ai fais un petit code pour expliquer:

ma lib javascript

Code:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
//mon package global, je le rend compatible avec les differents loaders possibles
//si aucun loader, fini en objet global de toute façon
(function (window, factory) { 
        if (typeof define === 'function' && define.amd) define(factory); // AMD
        else if (typeof exports === 'object') module.exports = factory(); // Node
        else window['FTW2'] = new(factory())(); // globals: ici, j'ai rajouté new, pour avoir une instance, alors 
        //que tu ne le fait pas, mais si tu ne passe que le constructeur, comment tu accedes au methodes?
        //charge a l'utilisateur de l'initialiser?
        
        //si je veux reagir au window.load, ca me semble etre un bon endroit pour le mettre, non?
        console.log("j'ai quoi dans ma globale?");
        console.log(window['FTW2']);//par curiosité
        
}(this, function () {
 
        //je cree mes objets, fonctions....
        //en profitant de la closure
        function JusteUnTest(n,p){
                this.name = n;
                this.prenom = p;
        };
        JusteUnTest.prototype.sayHello = function(){ console.log("hello "+this.name);};
 
        
        
        //mon namespace PRINCIPAL
        //c'est lui qui expose les méthodes et données de ma lib
        //juste une question: la méthode factory renvoie le constructeur, AMD et Node se charge
        //de l'initialisation? Si oui, quel nom ils donnent à l'objet? 
        function FTW2 (){
                this.moi = new JusteUnTest("Stephane","ST3FF");                
        };
        //je ne rends accessible que 2 methodes
        FTW2.prototype.setInfos = function(n,p){
              this.moi.name = n;
              this.moi.prenom = p;
        };
        FTW2.prototype.hello = function(){if (this.moi)this.moi.sayHello();}
 
 
 
        //un sous package pour acceder facon FTW2.SECOND.une_fct()
        //ici, pas besoin du loader particulier, je peux faire ca a la main?
        //mais pour rester dans l'esprit, je crée encore une closure.
        FTW2.prototype.SECOND  = new ((function (){         
         
                //une methode interne, elle ne regarde personne
                function un_message(){
                        console.log("un super message;");
                };
                //un objet 
                function un_objet (){
                        this._message = "youhou";
                };
                
                //mon sous-namespace
                function SECOND (){ 
                        this.MaClasseInterneAuNamespace = un_objet;//je recup le constructeur
                };
                //les methodes/objets exposés par le namespace
                SECOND.prototype.showMessage = function(){
                      un_message();
                };
         
                //renvoie le namespace???
                //ie le constructeur|fonction
                return SECOND;
         
        })())();//?!!?!!???
        
        
        //renvoie le namespace???
        return FTW2;
 
}));

et dans ma page html, je peux ecrire un truc du style:

Code:

1
2
3
4
5
6
7
8
//les methodes exposées
FTW2.setInfos("Clara","Joahn");
FTW2.hello();

FTW2.SECOND.showMessage();
//cree une instance de classe interne
test = new FTW2.SECOND.MaClasseInterneAuNamespace ();
console.log(test._message);

Mon probleme, c'est que même lorsque l'objet se met dans les globals, vous ne semblez jamais l'initialiser?! C'est a l'utilisateur de la lib de l'initialiser comme il veut?

26/02/2016, 20h13
SylvainPV

Il ne faut pas utiliser l'opérateur new, une IIFE n'a pas pour fonction d'être un constructeur, juste d'encapsuler le code.

Ce que tu renvoies avec return à l'intérieur sera l'unique variable globale si aucun module loader n'est disponible. Cette variable peut être un namespace (un objet conteneur servant à stocker tout ce que tu veux à l'intérieur, jQuery par exemple est un namespace éponyme), ou alors un constructeur si ta lib repose sur ça.

Je ne sais pas ce que tu entends par "initialiser l'objet". Si tu as du code à exécuter pour préparer ta lib, l'IIFE est là pour ça.

Sinon j'ai pas trop compris ce que tu cherchais à faire avec new (function(){}())() mais une chose est sûre, c'est moche :p
27/02/2016, 09h38
st3ff

Bonjour,
je crois ne pas encore avoir tout à fait saisi comment ça marche, j'ai fait un essai, mais les closures/context de fonctions en javascript, et leur chaînage sont encore un peu flous dans ma tête...Par exemple, pour moi, créer une variable dans une fonction limite la portée à la fonction, j'ai trouvé l'explication du mot clé "var" et de ce qu'il se passait lorsqu'on l'utilise (ou pas) il y a pas très longtemps… Javascript a encore pas mal de subtilités que j'ai du mal a intégrer. Donc ce qu'il se passe avec une 'IIFE, je visualise pas encore.

Une nouvelle mise à jour sur GitHub. Au programme:

- Un dossier 'src': j'ai découpé le fichier source pour rendre le code plus lisible (et facile à debugger).
- Le ménage dans le code et suppression des commentaires inutiles (c'est fou ce que je peux laisser comme c*nneries la dedans! J'y trouverais une recette de cuisine ou la liste des courses que je serai pas plus surpris que ça)
- Sur vos bon conseils, j'ai crée une version UMD et minifiée de la lib (ftw2-min.js).Je continue à regarder comment ça fonctionne, je suis pas sur d'avoir encore tout à fait compris comment m'en servir...et je suis en train de me documenter sur les loaders de scripts, je garanti pas que ça marche pour l'instant…
- Du coup, j'ai du modifier quelques exemples de code (2way.html et item_presenter.html): la seule différence est que la méthode "generateUUID" définie dans FTW2 n'est plus accessible. (Au passage, aucune méthode n'est plus accessible. C'est plus simple et plus dans l'esprit de ce que je voulais faire)
- Une version de la doc en HTML. (Cela dit, les exemples de codes -dossier doc/exemples/*- sont ceux donnés dans la doc, j'ai juste copié le code html/js/css tel quel dans le pdf et ajouter des commentaires)

Dans le prochain épisode:

- Tenter de se débarrasser des surcharges de méthodes qui posent problème (les events listener,...). Je sens que pour le defineProperty, je vais quand même galérer…
- Ne pas obliger à créer un context de données en tant que variable globale (je pense à faire comme l'UMD, demander le constructeur? et me charger de l'instancier)
- Continuer le ménage dans les closures (en essayant de bien comprendre le truc)
- commencer à me pencher sur les Memory Leaks (et continuer d'apprendre à me servir des outils de profilage)
- écrire un readme!

On m'a demandé de choisir une licence pour FTW2, vous avez quelque chose contre la BeerWare? Je la trouve simple, courte à lire (parce que GPL, pardon!) et GPL-compliant.

Bonne lecture!
27/02/2016, 15h58
SylvainPV

Beerware, WTFPL, comme tu veux si ça t'est égal. Il faut juste mettre ça dans un fichier LICENSE sur ton repo. Par défaut si tu mets rien tu es protégé par le droit d'auteur, qui est assez restrictif.
03/03/2016, 09h38
st3ff
Salut,
J'ai apporté quelques modifications à FTW2:
- déclaration du data-context: désormais, il faut renseigner le nom du constructeur dans l'attribut "data-context" de la balise body, le framework se chargera de l'initialiser.
- définition des getters/setters: pour ne plus surcharger Object.defineProperty, j'ai crée une méthode 'statique' defineBindProperty (nom, descripteur). Un petit exemple:
Code:

1 2 function MonContext = { this.truc="machin"; …. }; MonContext.defineBindProperty("ma_prop",{get:, set:});
En plus, pour un gars qui vient de java/csharp/python, ça parait plus naturel comme ça

- suppression des surcharges des méthodes HTML.removeChild et addEventListener. En règle générale, j'ai aussi retiré toutes les données que je stockais dans les HTMLElement, maintenant, je n'y touche plus.
- suppression des item_presenters (notation spéciale pour les array/list): on utilise maintenant la même notation que pour les objets simples (ie: presenter) et je détermine au runtime comment traiter la donnée.
- des converters par défaut: je me laisse la possibilité de créer des converters (2 pour l'instant) pour les conversions 'usuelles'
- ajout de la licence: j'avais pas compris qu'il fallait un fichier dédié, donc merci pour l'info, j'ai rajouté!
- Du coup, j'ai mis à jour la doc et les exemples pour refléter les changements. J'espere pas avoir laissé trop d'erreur dedans. (dans le doute, j'ai retesté tous les exemples dans EDGE, Chrome et firefox)

Comme j'aimerai bien avoir une première version bientôt, j'ai décidé de geler les fonctionnalités du framework. J'ai bien conscience qu'il doit manquer plein de choses (d'ailleurs, si vous avez des idées…), mais je vais me concentrer sur le debug et l'optimisation maintenant.

Merci à tous pour vos retours.

J'ai mis l'application de démo Wolf Of WallStreet en ligne, si vous voulez essayer. (Et me dire si ça passe bien avec votre navigateur tant qu'à faire)
09/03/2016, 13h12
st3ff

Bonjour à tous
j'ai apporté quelques modifications internes à FTW2, et j'aimerais bien votre avis sur certaines:

- model binding: mise en place d'un recyclage pour les éléments html et les bindings en fonctions des data-types, pour maîtriser un peu mieux l'utilisation de la mémoire. Je sais pas si c'est une bonne idée de vouloir "gérer" la mémoire moi-même, ou si le navigateur et la VM ne préfèrent pas se charger de ça. Le recyclage, c'est un truc que je fais souvent en python, et qui est la plus part du temps conseillé, mais en javascript?

- en m'inspirant de la bibliothèque fastdom.js, j'ai déplacé les modifications du DOM dans un pool et utilisé les requestAnimationFrame pour les mises à jours.

Cette partie me pose un peu problème: en utilisant le profileur 'timeline', j'ai l'impression que la 1ere frame d'animation est appelée immédiatement (mais c'est peut être le comportement normal? Dans ce cas, il faudrait 'sauter' la 1ere frame pour faire un rendu sans mise à jour, puis commencer les modifs à partir de la seconde).
En plus, j'utilise un timer pour limiter les modifications DOM à 10ms, (auquel il faut ensuite ajouter le temps pour le layout et le paint), mais régulièrement, j'ai des frames marquées "Jank" (trop longue), ou bien le code a exécuter au début de RAF s'exécute en milieu de frame… (J'ai laissé le fichier de test dans les sources -src/utils/test_dom_batch.html-, si vous voulez voir de quoi je parle.) Bref ou j'ai rien compris au RAF, ou mon code a un gros problème que je ne vois pas.

Merci à tous