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

Le , par vermine

0PARTAGES

1  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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
1  0 
Avatar de 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/
1  0 
Avatar de yenicall
Candidat au Club https://www.developpez.com
Le 24/04/2014 à 11:11
>akrogames
Je ne suis pas d'accord avec toi : Tu affirmes que l'utilisation de moteur de rendu est une erreur de conception car les langages on un "moteur de rendu" intégré et que cela ajoute une complexité supplémentaire

Je vais pousser ce raisonnement vers l'absurde:

Pourquoi utiliser des frameworks comme Zend,Symfony, Jquery, Angular, alors que l'on peut très bien coder sans ces frameworks car ils ajoutent une complexité non négligeable ?
Pourquoi utiliser Doctrine VS PDO/mysqli en PHP ?
Pourquoi faire des interfaces graphiques alors que l'on peut directement écrire sur la console ?

Serte c'est vrai que tu peux afficher du texte avec echo en php, ou document.write en JS, mais tout comme les frameworks, ils (Moteurs de rendu) ne sont pas nécessaires mais ajoute une couche d'abstraction rendant la création d'application plus rapide et plus facilement maintenable.

Tu compares
Code : Sélectionner tout
<?php echo $this->name; ?>
à
Code : Sélectionner tout
{{name}}
La première méthode n'est pas difficile MAIS que ce passe-t'il si $this->name n'existe pas, tu as une belle erreur (alors oui tu peux les cacher mais ce n'est pas propre du tout).
La deuxième méthode transforme ton code en
Code : Sélectionner tout
<?php if(isset($this->name) && !empty($this->name)){ echo $this->name;} ?>
Ok ce n'est pas difficile mais répète ce morceau de code une centaine de fois, lequel des deux est le plus pratique à écrire ?

-------
Edition: Correction de mon orthographe, tournure de phrases
1  0 
Avatar de anykeyh
Membre confirmé https://www.developpez.com
Le 24/04/2014 à 13:34

Les moteurs de templating n'ont pas besoin d'exister car les langages intègre déjà des fonctionnalités d'affichage.
- Les frameworks MVC n'ont pas de besoin d'exister, car php/rack/asp font déjà du client-server
- Les moteurs de jeu 3D n'ont pas besoin d'exister, car openGL ou directX font déjà du rendu de triangles/pixel
etc...

En fait, le principe d'une bibliothèque, c'est justement de se greffer au dessus de ce qui se fait déjà. Si javascript/php n'intégraient pas de fonctionnalités d'affichage, comment un moteur de templating pourrait être produit dessus?

Il se trouve que ce genre de framework ajoute une surcouche (principe d'un framework, hein), afin de simplifier l'intégration, qui peut-être très pénible sur de gros projets.
On oublie souvent un point essentiel, à savoir que l'intégration c'est dur à tester. Les tests unitaires sur du rendu HTML, bof bof j'y crois pas trop (si quelqu'un a la recette magique je prend).

Alors on ajoute un peu de complexité là ou l'ont peut tester (initialisation de la lib, parametrage, création d'une architecture pour recuperer les templates etc), tout en réduisant la complexité là où c'est difficile à maintenir.

Je le vois comme ça, l'interêt des moteurs de templates/rendu.
1  0 
Avatar de 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...
0  0 
Avatar de 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é.
0  0 
Avatar de 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 ?
0  0 
Avatar de vermine
Responsable Jeux-Concours 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.
0  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 24/04/2014 à 13:06
Citation Envoyé par akrogames Voir le message
je n'ai pas besoin de lecture je connais parfaitement le sujet.
Ce n'est pas l'impression que j'ai eu Enfin, libre à toi de ne pas utiliser de templating JavaScript, si tu estimes ne pas en avoir besoin
0  0 
Avatar de kimjoa
Membre confirmé https://www.developpez.com
Le 24/04/2014 à 20:24
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.
write de JS permet d'afficher des éléments sur la page que si celle-ci n'est pas complètement chargé. Ça limite beaucoup son utilisation.

Il y'a une grosse différence entre le JS et le PHP, c'est que à la base le JS n'a pas été fait pour faire du templating, contrairement à PHP.
Y'a pas de balise sur la sortie standard, comme en PHP avec les <?php ?> ou <?= ?>, du coup tout ce base sur des strings, strings qui sont en JS très limité, pas d'interpolation, pas de multiligne!

PHP n'a pas besoin de moteur de template, lourd, lent, demandant un apprentissage, obligeant souvent à découpler la partie récupération des données et affichage des données. Il se suffit largement à lui même!

Il existe une solution simple et élégante reprenant le principe du PHP avec ses open tag, comme ejs, ou le micro-templating de jonh resign, et c'est vraiment pratique quand on veux pas se trimbaler des chaines à rallonge, source d’erreurs, sans aide à l’auto complétion, illisible.

Une autre solution est de s'abstraire du html et construire ses éléments directement avec le DOM, via un jeux de fonction simple pour limiter la verbosité de l'API, des fonctions du type hdiv([attributs], [...elements]). C'est la solutions que j'ai choisit au taf, car l'implémentation du data-binding est vraiment plus aisé et on reste sur du javascript. Pas de directive, ou autre pseudo code/attribut à définir... Besoin de capitaliser une chaîne, et un coup de toUpperCase et c'est terminé
0  0 
Contacter le responsable de la rubrique JavaScript

Partenaire : Hébergement Web