IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

ripple.js : templating JavaScript avec ajout de plugins


Sujet :

JavaScript

  1. #1
    Expert éminent sénior

    Avatar de vermine
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    6 582
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2008
    Messages : 6 582
    Points : 79 912
    Points
    79 912
    Par défaut ripple.js : templating JavaScript avec ajout de plugins
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      <div class="{{type}}">
         <img src="{{avatar}}" />
         {{ firstName + " " + lastName }}
      </div>
      Code javajscript : Sélectionner tout - Visualiser dans une fenêtre à part
      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 ?

  2. #2
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut Le templating c'est le mal
    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.

  3. #3
    Membre éprouvé Avatar de Shuty
    Homme Profil pro
    Ingénieur en développement
    Inscrit en
    Octobre 2012
    Messages
    630
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur en développement
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 630
    Points : 1 174
    Points
    1 174
    Par défaut
    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...
    Agence web Dim'Solution, créateur de solutions numériques
    Sites internet, ecommerce, logiciels, applications mobiles, référencement (SEO), plugin Prestashop, Magento, WordPress, Joomla!...

    Cours de trading gratuit | Envoyer des sms gratuitement | Envoyer des fax gratuitement | Plateforme de Fax à l'international

  4. #4
    Membre à l'essai
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Octobre 2011
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Octobre 2011
    Messages : 5
    Points : 15
    Points
    15
    Par défaut
    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é.

  5. #5
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Je suis le seul à voir une ressemblance frappante avec les Backbone.View et handlebars ?
    One Web to rule them all

  6. #6
    Expert éminent sénior

    Avatar de vermine
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    6 582
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2008
    Messages : 6 582
    Points : 79 912
    Points
    79 912
    Par défaut
    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.

  7. #7
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut
    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 - Visualiser dans une fenêtre à part
    <?php echo $this->name; ?>
    et plus difficile que :
    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

  8. #8
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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
    One Web to rule them all

  9. #9
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut
    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 - Visualiser dans une fenêtre à part
    $('#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.

  10. #10
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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/
    One Web to rule them all

  11. #11
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut
    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.

  12. #12
    Candidat au Club
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2014
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Avril 2014
    Messages : 1
    Points : 3
    Points
    3
    Par défaut
    >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 - Visualiser dans une fenêtre à part
    <?php echo $this->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 - Visualiser dans une fenêtre à part
    <?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

  13. #13
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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
    One Web to rule them all

  14. #14
    Membre confirmé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Octobre 2005
    Messages
    244
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Philippines

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Octobre 2005
    Messages : 244
    Points : 609
    Points
    609
    Par défaut
    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.

  15. #15
    Membre confirmé
    Profil pro
    Inscrit en
    Février 2009
    Messages
    354
    Détails du profil
    Informations personnelles :
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : Février 2009
    Messages : 354
    Points : 491
    Points
    491
    Par défaut
    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é

  16. #16
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut
    Les amis, le templating en JS tout comme en PHP, est totalement inutile, mais libre à vous d'utiliser, des bibliothèques inutiles et qui augmente le temps d’exécution de vos applis.

    Bref, libre à vous de faire des bêtises, mais conceptuellement c'est une aberration.

    anykeyh : - Les frameworks MVC n'ont pas de besoin d'exister, car php/rack/asp font déjà du client-server
    Je n'ai pas parlé de supprimer les frameworks type ZF, ou Jquery, j'ai juste dit que les moteurs de template ne servent pas. Apprendre à lire avant de critiquer.

    SylvainPV : Ce n'est pas l'impression que j'ai eu
    Désolé, mais si tu ne sais pas lire ou t'abstraire du quiproquo qu'il y a pu avoir, ce n'est pas de ma faute. Je te parle des langages, pas du moteur de rendu html côté client... Je n'ai jamais parlé du côté client.

    kimjoa : 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.
    Je suis d'accord avec toi avec la quasi-totalité de ton post, et tu confirmes que PHP est fait pour faire de base du templating. Et je te rejoins aussi sur le fait que JS de base, c'est compliqué d'intervenir dans le DOM directement. Mais JQuery par exemple fait très bien le boulot. Il n'y a pas besoin de moteur de templating lourd en surcouche.

  17. #17
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    Citation Envoyé par akrogames Voir le message
    Les amis, le templating en JS tout comme en PHP, est totalement inutile, mais libre à vous d'utiliser, des bibliothèques inutiles et qui augmente le temps d’exécution de vos applis.
    En réalité, à partir d'un certain seuil, utiliser une librairie de templating est plus performant car les économies en taille de code des templates viennent compenser le poids de la bibliothèque. C'est ce que j'explique dans mon article, prends le temps de le lire.

    Citation Envoyé par akrogames Voir le message
    Bref, libre à vous de faire des bêtises, mais conceptuellement c'est une aberration.
    Si je te suis, alors Google, Microsoft, LinkedIn et bien d'autres font des bêtises. jQuery ne répond pas aux besoins de templating ; d'ailleurs John Resig, créateur et lead developpeur de jQuery, a conçu et partagé sa propre solution de templating. Sa solution fait à peine 20 lignes de code ? En comparaison des 90ko de jQuery, ce genre de moteur de templating ne me paraît pas si lourd. D'ailleurs, des solutions ultra-légères de templating, il y en a pléthore.
    One Web to rule them all

  18. #18
    Membre actif

    Inscrit en
    Août 2005
    Messages
    401
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 401
    Points : 228
    Points
    228
    Par défaut
    Sylvain c'est pas cool de prendre des bouts de phrases hors contexte.

    Je vais répondre rapidement, mais quand tu dis :
    utiliser une librairie de templating est plus performant car les économies en taille de code des templates viennent compenser le poids de la bibliothèque
    , je ne suis fondamentalement pas d'accord car tu pars du postulat que la performance des moteurs de templating se base à la taille de ton code... J'ai envie de dire WTF... La performance d'un programme et sa maintenabilité ne se mesure pas à la taille du code.

    Je n'affectionne pas spécialement Jquery ou d'autres biblio, ce que je dis c'est juste que conceptuellement si tu n'arrives pas à t'abstraire du code (données, de l'affichage et du code métier) grâce au patron d'architecture qu'est le MVC, c'est qu'il y a un soucis. Je reformule un peu plus précisément, si nous nous embêtons à développer des mécanismes de templatings pour corriger les bêtises des développeurs, cela ne veut pas dire que tu dois les utiliser mais que tu peux aussi corriger tes erreurs de conception. Typiquement, en JS si tu fais des fuites mémoires, il ne faut pas attendre que le langage te force à corriger tes erreurs.

    Pour finir, au niveau de PHP je parlais côté serveur, et PHP est un langage de templating puissant. Côté client, JS de base n'est pas très performant pour gérer et interagir avec les documents DOM, toutefois, avec des frameworks, il devient simple d'instaurer une architecture MVC par classe et du coup pas besoin de moteur de template. Les langages de base intègre des fonctionnalités d’interaction avec le système rendu.

    Bon j'en reste là vu que de toute manière on ne sera pas d'accord. Bonne journée à toi.

Discussions similaires

  1. [OL-2010] Template outlook avec ajout de champ
    Par janlouk dans le forum Outlook
    Réponses: 0
    Dernier message: 22/12/2014, 15h15
  2. Affichage d'une template contenant du javascript avec firefox
    Par ahmedpa dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 18/08/2013, 22h49
  3. Ajout d'attributs et methodes a plusieurs objets JavaScript avec JSON
    Par zarbi94 dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 12/05/2010, 19h20
  4. Réponses: 7
    Dernier message: 19/05/2009, 12h15
  5. [PHP-JS] var javaScript avec test php
    Par lepierre dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 01/12/2004, 13h58

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo