ripple.js : templating JavaScript
Avec ajout de plugins propre aux vues et aux composants

Le , par vermine, Responsable JavaScript & AJAX
ripple.js : templating JavaScript avec ajout de plugins propre aux vues et aux composants

ripples.js est une bibliothèque JavaScript pour la création de modèles (templates) et la liaison de données (data binding) construite par Segment.io. Elle s'articule autour de templates et a une API permettant d'ajouter des plugins aux composants.

On y retrouve des similitudes avec Reactive (observables, etc.), AngularJS, Handlebars et React (construction d'interface utilisateur). La différence majeure avec les autres bibliothèques de ce genre est qu'il n'y a aucune utilisation globale. Chaque vue a son propre ensemble de plugins et de liaisons.

Code javascript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
var Person = ripple('<div>{{name}}</div>') 
   .use(events) 
   .use(each) 
   .use(dispatch); 
  
var person = new Person({ 
   name: 'Tom' 
}); 
  
person.appendTo(document.body);


Il y a un exemple qui utilise un modèle intégré dans un élément script et deux plugins : ripple.events et ripple.markdown. Les plugins autorisent l'observation des modifications dans une textarea et la seconde partie est configurée pour afficher le résultat à l'aide d'une directive sur un élément div.

Le modèle pour la composition de la vue permet que cette dernière soit intégrée et que les données seront toujours synchronisées lorsque la vue change.

La bibliothèque comporte par exemple :

  • l'utilisation de template HTML avec les accolades comme délimiteur ;
    Code html : Sélectionner tout
    1
    2
    3
    4
    <div class="{{type}}"> 
       <img src="{{avatar}}" /> 
       {{ firstName + " " + lastName }} 
    </div>
    Code javajscript : Sélectionner tout
    1
    2
    3
    4
    5
    6
    { 
       "type": "winner", 
       "avatar": "http://ragefaces.io/rage.png", 
       "firstName": "Nicolas", 
       "lastName": "Cage" 
    }
  • l'intégration avec Component (fichier json) ;
  • la manipulation du DOM (appendTo, replace, before et after) ;
  • des événements (construct, created, ready, etc.) ;
  • des getters et setters.


Téléchargement (version 0.3.2).
La page GitHub.
D'après un article sur DailyJS.

Et vous ?

Que pensez-vous de cette bibliothèque ?

Quel outil utilisez-vous pour faire vos templates ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de akrogames akrogames - Membre actif https://www.developpez.com
le 23/04/2014 à 11:16
Le templating c'est mal, cela relève d'un problème de conception et de modélisation... C'est un peu comme Smarty en PHP, complètement inutile.
Avatar de Shuty Shuty - Membre éprouvé https://www.developpez.com
le 23/04/2014 à 12:04
Citation Envoyé par akrogames  Voir le message
Le templating c'est mal, cela relève d'un problème de conception et de modélisation... C'est un peu comme Smarty en PHP, complètement inutile.

Pour le coup, je ne suis absolument pas du même avis que toi ! Le templating permet ou plutôt aide principalement les intégrateurs / designers à concevoir simplement leurs design sans pour autant connaitre les profondeurs d'un langage de développement.

Je ne suis pas un grand amoureux de Smarty (je préfère Twig) mais il s'avère être d'une grande utilité. C'est pourquoi Prestashop l'utilise...
Avatar de teddyFry teddyFry - Membre à l'essai https://www.developpez.com
le 23/04/2014 à 14:23
Citation Envoyé par akrogames  Voir le message
Le templating c'est mal, cela relève d'un problème de conception et de modélisation... C'est un peu comme Smarty en PHP, complètement inutile.

Je ne vois pas trop en quoi le templating est un problème de conception. Que l'on pousse les informations via du binding de données ou que l'on parse un fichier template le principe reste le même et dans tous les cas un moteur de rendu se charge de générer l'interface utilisateur.

Le but étant de séparer la génération de l'interface de la manipulation des données. L'erreur serait pour moi de générer du code HTML dans son code.

En tout cas un tel framework doit prendre tout son sens avec Node.JS, j'essayerai ça ce week-end par curiosité.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 23/04/2014 à 14:54
Je suis le seul à voir une ressemblance frappante avec les Backbone.View et handlebars ?
Avatar de vermine vermine - Responsable JavaScript & AJAX https://www.developpez.com
le 23/04/2014 à 15:09
Non.

Citation Envoyé par vermine  Voir le message
On y retrouve des similitudes avec Reactive (observables, etc.), AngularJS, Handlebars et React (construction d'interface utilisateur). La différence majeure avec les autres bibliothèques de ce genre est qu'il n'y a aucune utilisation globale. Chaque vue a son propre ensemble de plugins et de liaisons.

Il faut voir s'il y a vraiment de la valeur ajoutée.
Avatar de akrogames akrogames - Membre actif https://www.developpez.com
le 23/04/2014 à 15:15
Shuty et teddy :

"Je ne vois pas trop en quoi le templating est un problème de conception." => C'est un problème de conception car la plupart des langages disposent déjà de cette fonctionalité de sortir l'affichage du code de base. Et malheureusement ces outils rajoute une complexité qu'un programme ne devrait pas avoir vu que le langage sous-jacent gère cette problématique.

"Le templating permet ou plutôt aide principalement les intégrateurs / designers à concevoir simplement leurs design sans pour autant connaitre les profondeurs d'un langage de développement." => Encore une fois c'est faux, et si tu vois ce genre de problème dans tes codes, c'est que tu as un problème de modélisation.

Pourquoi ? Tout simplement parceque les langages gèrent la séparation de la vue et du modèle. Explique moi en quoi ce code :
Code : Sélectionner tout
<?php echo $this->name; ?>
et plus difficile que :
Code : Sélectionner tout
{{name}}
outre le fait que cela rajoute un problème de sémantique dans tes données ?

PHP et Javascript sont eux-mêmes des moteurs de rendu, pourquoi ajouter une couche supplémentaire pour faire exactement la même chose ?

C'est d'ailleurs étrange que personne ici n'est rejoins mon camp. M'enfin j'ai déjà rasmus lerdorf avec moi
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 23/04/2014 à 16:27
Citation Envoyé par akrogames  Voir le message
C'est un problème de conception car la plupart des langages disposent déjà de cette fonctionalité de sortir l'affichage du code de base. Et malheureusement ces outils rajoute une complexité qu'un programme ne devrait pas avoir vu que le langage sous-jacent gère cette problématique.

"La plupart des langages" n'inclut pas JavaScript, or c'est une lib JavaScript !

PHP et Javascript sont eux-mêmes des moteurs de rendu

Euh non absolument rien à voir avec un moteur de rendu
Avatar de akrogames akrogames - Membre actif https://www.developpez.com
le 23/04/2014 à 19:01
Euh non absolument rien à voir avec un moteur de rendu



Désolé mais quand tu fais un echo, en PHP, où quand tu utilises la méthode write de javascript cela écrit (pour JS), dans le document dom. C'est des fonctionnalités de rendus, tu peux le nier mais c'est la cas.

"La plupart des langages" n'inclut pas JavaScript, or c'est une lib JavaScript !

Comme dis plus haut, Javascript dispose déjà de fonctionnalité d'affichage, pas la peine de complexifier le tout avec un moteur de template, lourd. La plupart des framework JS, intègre de quoi écrire dans le document DOM, comme Jquery quand tu fais :
Code : Sélectionner tout
$('#test').html("FOO");
C'est pourtant pas plus compliqué que d'utiliser un moteur de template moche et lourd.

D'ailleurs en PHP, Zend avec ZF ne recommande pas d'utiliser son système de templating Zend_View avec Zend_View_Interface, type smarty car PHP lui-même un moteur de gabarit puissant. C'est pareil en JS. Idem.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 23/04/2014 à 21:09
Non, le moteur de rendu c'est le composant logiciel intégré à ton navigateur qui permet de dessiner les pages Web. Webkit, Gecko, Trident, Servo sont des moteurs de rendu. JavaScript et PHP sont des langages de programmation.

Utiliser innerHTML peut convenir pour des cas simples, mais quand on parle d'applications web riches, les modèles de page et les interactions sont bien trop complexes pour qu'on puisse se contenter de cette solution. C'est tout l'intérêt du template : rendre plus lisible et maintenable la génération de larges pans de HTML en JavaScript.

Je te suggère un peu de lecture : http://sylvainpv.developpez.com/tuto...lating-client/
Avatar de akrogames akrogames - Membre actif https://www.developpez.com
le 24/04/2014 à 9:25
Je te parle des fonctionnalités de rendu des langages et tu me sors les moteurs de rendus côté client sur les navigateurs... je n'ai pas besoin de lecture je connais parfaitement le sujet.

Et je ne te parle pas de la surcouche innerHtml mais de la fonctionnalité write de JS. Les moteurs de templating n'ont pas besoin d'exister car les langages intègre déjà des fonctionnalités d'affichage.
Offres d'emploi IT
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Expert décisionnel business intelligence H/F
Safran - Ile de France - Évry (91090)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique JavaScript : Xavier Lecomte -