web-dev-qa-db-fra.com

Meilleure stratégie pour utiliser le modèle HAML avec Backbone.js

Je commence à utiliser Backbone.js pour structurer le code javascript de mon projet et j'adore HAML pour la modélisation sur le backend (Rails). Je voudrais donc l'utiliser pour la modélisation Backbone Views. Je sais qu'il existe plusieurs ports HAML vers Javascript, tels que https://github.com/creationix/haml-js et que backbone prend en charge JST et moustache avec facilité. 

Quel est le meilleur moyen d’utiliser plutôt que des modèles haml?.

Y a-t-il des inconvénients à utiliser HAML du côté client? Performances, temps de chargement de script supplémentaire (pris en charge par des outils de packaging tels que jammit)

javascripttemplateshamlbackbone.js
38
Vladimir Gurovich

Je sais que vous en avez déjà parlé, mais je suggérerais d'utiliser haml-js avec Jammit. Incluez simplement haml.js dans vos javascripts et dans votre fichier assets.yml, ajoutez template_function: Haml, ainsi que vos fichiers de modèle dans un package. par exemple.

  javascript_templates:
    - app/views/**/*.jst.haml

Ensuite, dans vos vues, vous pouvez inclure ce package (= include_javascripts :javascript_templates) et Jammit conditionnera tous les fichiers .jst.haml dans window.JST['file/path']. (Si vous affichez la source de la page, vous devriez voir un fichier javascript comme <script src="/assets/javascript_templates.jst" type="text/javascript"></script>.)

Pour utiliser ces modèles, appelez simplement l’un des JST créés par Jammit. c'est à dire.

$('div').html(JST['file/path']({ foo: 'Hello', bar: 'World' }));

Et Jammit utilisera la fonction de modèle Haml-js pour rendre le modèle.

Remarque: Assurez-vous de pointer le repo github de Jammit dans votre Gemfile pour obtenir la dernière version prenant en charge les caractères de nouvelle ligne nécessaires au bon fonctionnement de haml-js.

26
Craig

Je suis sur le point de donner haml-coffee un coup de feu. (sans jeu de mots) Je ne peux pas assez louer le coffeescript; De plus, c'est un défaut maintenant dans Rails 3.1. Maintenant, je peux intégrer Coffeescript dans mon langage de templates préféré et pré-compiler le lot. 

Oh, la joie ... maintenant de le faire fonctionner.

14
Duke

Je sais que cela tournerait un peu autour de la question mais on y va :)

J'utilise l'application Rails J'utilise haml pour toutes les vues sur le backend. C'est génial. Pour certaines raisons (principalement i18n), je n'aime pas utiliser les modèles côté client. Voici comment je le fais:

  • créez tous vos modèles dans Ruby haml et stockez-les dans une balise script avec un type original (j'utilise text/js-template). Cela créera du code HTML prédéfini avec lequel vous pourrez jouer avec jquery et backbone.
  • lorsque vous créez vos vues de dorsale, chargez le modèle stocké et ajoutez-le à votre document
  • Rendez votre vue en modifiant le modèle préexistant

Vous ne traitez qu'avec du HTML et jQuery est génial pour cela. Pour certaines vues qui ne nécessitent pas i18n, j'utilise des modèles de soulignement, car elles sont déjà présentes.

En ce qui concerne les performances des modèles haml, il semble que la moustache et le guidon soient plus rapides. 

6
Julien

Je travaille sur l'application Rails 3/Backbone et j'ai adopté une approche différente après avoir évalué hamlbars , haml_assets , et joué avec haml-js . 

Ce sont tous des joyaux solides qui offrent des solutions au problème, chacun ayant un certain ensemble de compromis. Haml-js, par exemple, nécessite de rendre les modèles de rendu côté client (il n'y a rien de mal à cela, c'est simplement un compromis). Hamlbars et haml_assets sont tous deux connectés au pipeline d'actifs, mais, comme ils existent en dehors de l'objet de requête, certains assistants ne fonctionneront pas. Les deux font des ajustements pour cela et incluent des aides d'URL et d'AideView, mais ne vous attendez pas à avoir les mêmes fonctionnalités que l'écriture de haml dans une vue.

Mon approche est quelque peu volumineuse (je prévois de le mettre dans un moteur), mais cela fonctionne bien et peut être facilement reproduit. Il utilise haml_assets lorsque cela est possible, mais retombe sur le traitement d'un modèle à partir d'un contrôleur "de modèles" avec une action "show" 

  • Placez vos vues dans le dossier view/templates /
  • Vous pouvez ajouter une mise en page qui rend cette vue dans une fonction JST
  • Vous pouvez spécifier l'action show pour renvoyer "application/javascript" comme type de contenu.
  • Vous avez accès à toutes les aides lors de la rédaction de modèles
  • Vous pouvez ajouter des balises de script pour "/ modèle/quel que soit" qui rendra le modèle, ou utiliser le déplacement de route pour des vues mieux organisées.

L'avantage de cette approche est que, comme vos vues sont accessibles depuis les contrôleurs, vous avez la possibilité de les restituer sous forme de modèles jst (via le contrôleur de modèles) ou via d'autres contrôleurs sous forme de partiels. Cela vous permettrait de servir des pages conviviales directement à partir d'URL (comme/products/widgets/super-cool-widget) où les utilisateurs peuvent obtenir le modèle mis en cache/templates/widgets/super-cool-widget.

2
mhamrah

Je ne peux pas répondre en ligne sur le fil de Craig (j'imagine que j'ai besoin d'une sorte de réputation pour publier des réponses sur des réponses existantes), mais vous n'avez plus besoin de saisir un fork de jammit pour utiliser haml-js - le commit l'a intégré la branche principale de jammit. Voir ici pour plus de détails: https://github.com/documentcloud/jammit/commit/b52e429f99cac3cd1aa2bf3ab95f1bfaf478d50d

EDIT: la dernière publication de gem date de janvier et les commits ont été ajoutés en mars. Vous devez donc configurer le bundler pour qu'il s'exécute sur le référentiel github ou le construise localement. Si vous n'utilisez pas HEAD de jammit, vous aurez des difficultés à analyser correctement les modèles car les nouvelles lignes sont supprimées.  

Tout ce que j'avais à faire pour configurer ceci est:

1) Ajoutez les éléments suivants à mon fichier "assets.yml": 

template_function: "Haml"

2) Ajoutez la source haml-js et les modèles que je voulais charger dans mon fichier d’actif: Javascripts: ____.] modèles: - app/views/events/_form.haml.jst

3) Assurez-vous que je chargeais le noyau et les modèles dans mon application.html.erb

<% = include_javascripts: core,: templates%>

4) Accéder aux modèles dans mes fichiers sources via JST [nom du fichier] (c'est-à-dire, dans ce cas, JST ['_ form']]). Un point à noter: jammit examinera tous vos modèles et les placera dans l’espace de noms jusqu’au chemin commun. Si vous avez app/views/foo/file.jst et app/views/bar/file.jst, vous aurez accès avec JST ['foo/file.jst'] et JST ['bar/file.jst']. Si vous aviez app/views/foo/file1.jst et app/views/foo/file2.jst, ils seraient directement à JST ['file1.jst'] et JST ['file2.jst'] - ce qui est facile à oublier lorsque vous commencez avec vos premiers modèles.

Tout a fonctionné assez bien. Je ne sais pas pourquoi Craig avait besoin de définir une fonction - je viens d'utiliser la fonction Haml par défaut fournie par haml.js, mais peut-être qu'il me manque quelque chose. 

1
ragaskar

On dirait que https://github.com/netzpirat/haml_coffee_assets vous donne ce que vous voulez. (Modèles window.JST, écrits en HAML, avec prise en charge intégrée du coffescript)

0
Jordan Feldstein

Découvrez Middleman. Il comprend haml, sass, coffee, slim, etc. Il utilise des pierres précieuses comme le fait Rails et possède de nombreuses autres fonctionnalités impressionnantes.

http://middlemanapp.com/

Ils ont même une extension personnalisée pour backbone, https://github.com/middleman/middleman-backbone

Il vous permet également de le compiler en html, css et js statiques pour un chargement ultra rapide.

0
Blaine Hatab