• Site officiel [EN]
• Code source sur Github

Comment débuter ?

• Ember CLI - squelette et outils pour construire des applications avec Ember.js
• Ember Extension/Inspector: pour Chrome (via Web Store),  Firefox (via addons.mozilla.org). Il est possible de l'installer directement via Github (je recommande de passer par GH)
• Ember JsBin

Exemple d'applications

http://builtwithember.io/ recense les sites construits grace à Ember.js

• LiveNation
• https://fnd.io/ :  Itunes et App Store disponible via une web app.
• Discourse Un forum open source (MesDiscussions n'a qu'à bien se tenir )

Qui l'utilise ?

De la startup au grand groupe ( LinkedIn, Apple, Netflix, Groupon, ...)

A COMPLETER

RESERVE

Routeur

Controlleur

Template / View

Component

RESERVE

Ember Data

Model

Adapteur

Serialiaseur (??)

Drap' ça m'intéresse faut juste que le trouve le temps de tester

Il va me falloir un bout de temps pour remplir les 1er posts (même si je ne compte pas faire une traduction des guides), faut pas hésiter à poser des questions.

https://github.com/nraynaud/webgcod [...] ew.js#L133
donc, pour revenir à notre discussion, est-ce qu'il y a mieux que faire ça ?

J'ai moyen de faire tourner ce code en local ?

c'est un poil relou, il te faut un serveur web (l'unique template est attrappé par du XHR), par contre c'est 100% statique (donc apache marche).

le code lui-même est en ligne là : http://nraynaud.github.io/webgcode/text.html

edit: pour bosser sur ce code, je nique cette ligne https://github.com/nraynaud/webgcod [...] ew.js#L154
comme ça:

return {x: bottomLeft.x + width * 0.3, y: bottom + height * 0.2, width: width * 0.6, height: height * 0.6}

ça donne un viewport virtuel plus petit que le viewport réel et on peut surveiller ce qu'il fait hors de l'écran

y'a moyen d'avoir ember au moins compatible avec require.js ?  
 
genre qu'il charge au moins le jquery chargé par require.js ?  
 
là c'est n'importe quoi y'a la moitié des fichiers chargés par <script> et l'autre moitié par require.js. Et je me retrouve avec 2 instances de jquery.

http://emberjs.com/guides/routing/
j'aimerai bien voir un exemple de routage qui concerne le fait d'être loggé ou pas. parce que là je suis un peu interloqué.

 
Le portage du code vers des modules ES6 n'est pas fini.
 
Par contre il est possible d'initialiser Ember avec une version spécifique de jQuery qui n'est pas sur le global object avec Ember.imports. Donc si on a moyen de récupérer l'instance chargée par require.js, ca doit être possible en attendant la fin du portage vers des modules ES6.
 
C'est pas documenté tout ça pour le moment par contre, il va falloir que je fasse mumuse dans un jsbin pour tester car je n'ai jamais fait.

 
Tu peux regarder du côté de l'implémentation d'ember-simple-auth
 
https://github.com/simplabs/ember-simple-auth
 
Et plus particulièrement l'implémentation du mixin qui va bien
 
https://github.com/simplabs/ember-s [...] e_mixin.js
 
En gros tu as un object session dans ton appli, et la route vérifie que l'utilisateur est authentifié pour valider la transition.

merci.
 
http://emberjs.com/api/classes/Ember.Select.html
J'ai une question bête j'ai un select, sa valeur arrive au démarrage de l'appli, mais ses options arrivent de manière asynchrone plus tard. Quand les options arrivent, c'est pas la bonne option qui est sélectionnée visuellement. Y'a moyen de corriger ça ?  
 
(http://nraynaud.github.io/webgcode/text.html le select des fonts, il devrait afficher 'Seymour One' quand il se rempli)

C'est un bug connu, Ember.Select est un attente de réecriture pour mieux gérer le côté asynchrone.

https://github.com/emberjs/ember.js/issues/4150

Une solution rapide (et potentiellement meilleure de toute façon) est d'attendre d'avoir chargé tes fonts pour gérer l'affichage.

Au lieu de le faire dans ton controlleur comme tu le fais actuellement, déplace ce code dans la fonction `model` de ta route.

merci. En fait j'ai pas encore creusé cette histoire de routes.
 
à titre d'information, cette route elle correspond à quelle (fragment d') URL ?

J'ai utilisé l'Ember Inspector pour voir comment est codé ton appli.

Ca te montre l'url du coup aussi.

J'ai pu voir que c'est la TextRoute qui est chargée et qui utilise le TextController.

La fonction `model` de la route doit servir à charger les données. Tu le faisais déjà partiellement, mais en plus tu charges d'autres données (les fonts) lors de la création du controller (dans la méthode `init` du TextController). La fonction `model` attend en retour une promise et est bloquante tant que cette promise n'est pas résolue.
Ca résoud ton problème car la vue n'est pas créée/insérée avant que toutes tes données soient chargées.

Si tu as besoin des fonts de manière générale dans ton application, tu peux toujours charger les fonts dans l'ApplicationRoute (autogénérée si tu ne l'as pas définie)

Ok je vais essayer de faire ça, genre dans mon cas, y'aurait une route pour la liste des fonts, une route pour le modèle et une route pour charger "la" font ?

Pas vraiment, une route = une url = un état (state) de ton appli.
 
De ce que je vois de ton appli, tu ne navigues pas, tu as une seule vue. Donc avoir une seule route semble correct.
 
Par contre, je séparerais effectivement qui prend en charge quelles données.
 
Avoir un FontsController qui contient toutes les polices et un TextController qui contient les données propres à ton appli (tout sauf la liste de fonts) serait un bon début.
 
Tu peux ensuite utiliser l'attribut `needs` pour que ton `TextController` dépende du `FontsController`( cf http://emberjs.com/guides/controll [...] ntrollers/  )
 
Dans ton template, la déclaration de ton Ember.Select ressemblerait plus à
 

 
Tu charges les options à partir du FontsController, mais la sélection est gérée par le TextController.

ok, merci.

Quels sont les avantages et inconvénients de cette techno comparativement aux autres Framework du meme genre ?
 
En gros si tu peux resumer, qu'apporte Ember de plus/de différent ?
 
Merci, je  ne connaissait pas

Ah merde, j'avais pas capté, je veux pas mettre la liste des font dans mon modèle, c'est plutôt un truc intrinsèque à l'application. Si je devais sauver le modèle je veux pas sauver la liste des fonts dedans.

il sort d'où le symbole 'controllers' de l'exemple ?
Je pense que je vais investiguer cet arrangement parce qu'il a l'air sémantiquement juste, mais je sens que ça va pas résoudre mon bug initial.

 
   
 
J'ai fait qu'un copier/coller de ton côté pour placer dans une autre fonction.
 

 
C'est obtenu grace à `needs` dans le `TextController`. C'est pas ça qui résoud ton problème, mais le fait de charger les fonts dans une promise dans la fonction `model` de `TextRoute`.

ouais, mais du coup dans ma solution à 2 contrôleur, il faut une route séparée pour la liste des fonts ?  
comment le système sait qu'il doit aller chercher cette route ?

Je ne peux pas te répondre d'expérience personnelle, mais uniquement sortir des arguments lus/entendus.

Backbone.js est un micro framework. Ca ne fait pas grand chose de base, ne tente pas de dire comment faire. Des gens développent des plugins que tu dois rajouter, et gérer les problèmes associés. Plus léger, mais ca n'a pas l'objectif de faire des applis "compliquées".

Angular permet de faire globalement la même chose qu'Ember (mis à part les Components). Lors d'une présentation de Yahoo!, le responsable expliquait qu'ils avaient étudiés les 2 solutions. Son expérience était qu'Angular est plus facile d'approche, mais plus le projet avancait, plus ca se compliquait. Alors qu'avec Ember, une fois la première phase d'apprentissage passée, bien plus rude, le niveau de complexité évolue peu.

J'ai entendu des gens abandonner Ember car c'était trop compliqué pour eux d'arriver à qqch pour passer à Angular, et des gens abandonner Angular pour Ember car plus ils voulaient réaliser de choses compliquées, moins Angular suivait.

Il faut surtout se méfier de nombreux articles qui traine sur le web. Non pas qu'ils soient nécessairement faux, mais le framework a énormément évolué et cela très rapidement.
Je ne prendrais pas en considération tout article publié avant la release de la version 1.0, tant ca ne reflète plus ce qu'est le développement avec Ember.

De la même manière, beaucoup d'articles critiquent Ember alors que le problème vient d'Ember Data, plus ou moins à juste titre. Ils oublient généralement 2 choses:
- la concurrence n'a pas d'équivalent qui fonctionne
- tu peux utiliser Ember sans Ember Data

Qui plus est, ember data a été "rebooté" dernièrement pour offrir une meilleure base à même d'atteindre l'objectif compliqué qui est le sien.

Tu récupères tes fonts dans la method `model`, et tu les passes au `FontsController` dans la methode setupController.

(J'avais testé les autres codes et validé que cela corrige ton problème, là je tape sans tester, il y a peut être des erreurs de syntaxe, etc..)

ouais, ouais, t'es pas mon sous-traitant je demande juste des explication haut niveau, parce que tout est "par convention" et le code est imbitable, du coup y'a que en demandant à quelqu'un qui connait qu'on peut trouver des réponses qui sont pas dans les guide.
 
Merci, je vais tester ça en première étape.

ça marche

 
 
Ok merci je vois
 
Le truc c'est que j'etait a 2 doigts de passer a Durandal JS (Qui est un genre d'Angular, sauf ce c'est un wrapper autour de jQuery/Knockout/Require avec le systeme de route etc...)
 
Puis j'ai appris hier que le mec de Durandal bosse maintenant chez Angular, et qu'ils comptais fusionner les avantages des 2 projets sous le nom de Angular 2.0
 
Ca s'annonce vraiment tres puissant d'ou mon hesitation entre patienter pour ca et monter en competence sur Ember    
 

 
Plus que la solution, ce qui est important, c'est que j'explique pourquoi ca marche.
 
Quand tu architectures ton appli, tu vois les différentes urls qui t'intéressent. Tu construis ensuite tes routes pour exposer ces urls.
 
La manière simple de voir la suite, est qu'une route représente une resource/vue qui expose des infos sur un modèle. Le modèle est chargé dans le controlleur. Le controlleur sert de contexte à la vue.
 
Donc, `model` retourne l'object que l'on veut utiliser dans la route/vue, sous forme de promise. Même si tu ne retournes pas une promise, ca va être encapsulé pour toi par le framework.
Ensuite le framework assigne par défaut ce modèle au controlleur correspondant (trouvé par convention de nommage: TextRoute -> TextController -> TextView -> text template) dans `setupController`. Dans ton cas, tu veux assigner également la liste de fonts. C'est pour ça qu'on surcharge `setupController`.
 
Comme le contexte de la vue est le controlleur, si on utilise l'attribut `needs` dans le `TextController`, tu peux écrire `controllers.fonts` dans la vue.
 
J'espère que c'est clair.
 

 
On avait fait le pari Ember il y a plus de 2 ans dans mon ancienne boite, et je ne le regrette pas. Après j'ai aussi une relation particulière, ca a été lancé sur SF, je contribue, participe aux meetups, connais personnellement tous les membres de l'équipe core et de nombreux contributeurs. Participer à un projet open source, supporté par une communauté et non pas par Google, c'est une satisfaction pour moi. Et quand je vois le chemin parcouru et les têtes derrières, je sais que je n'ai pas fait le mauvais choix (même s'il n'y a pas vraiment de mauvais choix dans ce cas précis).
 
Quand je vois que Marissa Meyer a donné le feu vert pour que tous les nouveaux projets chez Yahoo! soient faits sur Ember, ca commence pareil chez Netflix et probablement LinkedIn bientôt, je n'ai pas de crainte quand à l'avenir. Et de toute manière, acquérir la maitrise dans un de ces frameworks est forcément un plus qui doit permettre de transitionner plus rapidement à un autre dans le pire des cas.

question basique, les instances de contrôleur y'en a une par modèle ? une pour chaque type qu'on re-bind pour chaque vue ?
 
dans mon code, j'ai ça :  

TextApplication.FontsController = Ember.ArrayController.extend({
 
                });

Y'a moyen de faire mieux ?

tu vis où à SF ? ma nana veut aller là-bas, mais moi les loyer ils me font flipper et puis j'ai un peu l'impression d'arriver après la bataille (et comme j'ai pas de bagnole, je peux pas aller vivre n'import où).
 
Tom Dale il est pas à Portland ?

TextApplication.FontsController = Ember.ArrayController.extend({
 
                });

TextApplication.FontsController = Ember.ArrayController.extend();

Si tu veux sauver des charactères

Dans ton cas c'est le minimum que tu ais besoin de coder (pas de conventions pour déduire le type d'un controlleur qui ne sert pas dans une route).

SF

Les mecs de Tilde ont bougé sur Portland l'été/automne dernier. Tom habitait à une 10aine de bloc de chez moi.
Le problème pour venir aujourd'hui est de toute manière l'obtention d'un visa.

ça va finir avec une bague tout ça. sauf si j'arrive à la convaincre d'aller au Canada.

Bon y'avait Yehuda Katz des le debut en core dev, on peut pas dire que c'était anonymous non plus Ember...

J'ai du mal à comprendre l'intérêt des composants, y'a moyen de packager dans un fichier unique un bout de handlebars, un bout de CSS et une définition de classe ?
 
 
D'autre part, ça marche comment le nommage ? dans l'exemple ils nomment le composant dans l'espace de nom global de l'application ce qui semble un peu limité si on veut le ré-utiliser entre applications.

 
Il ne me semble pas avoir dit que c'était des anonymes.
 

 
Faut lire la spec pour les Web Components: http://www.w3.org/TR/components-intro/
 
Le but c'est d'avoir des widgets en totale isolation du reste du code. Ca a ses limites avec Ember ( pas possible de "scoper" le CSS), mais un effort est mis pour séparer le code Component vs non Component.
 
Le nommage est :
- nom en 2 mots
- pour le template avec un prefix "components/"
- pour la classe: suffixe "Component"
 
 
Donc un composant "Text" ne devrait pas fonctionner, mais "TextArea" devrait passer:
- template: "components/text-area"
- TextAreaComponent pour la classe.
 
Un composant a une particularité : il s'agit d'une vue dont le contrôleur est la vue elle même.

http://www.w3.org/TR/components-intro/#imports-section
C'est ça qui répond le plus à ma question, est-ce que c'est implémenté (ou proche) dans Ember ?
 
 
dans l'exemple Ember, ils l'appellent pas simplement "TextAreaComponent", mais "App.TextAreaComponent" ce qui fout en l'air toute notion de ré-utilisabilité. est-ce qu'il y a moyen de faire mieux ?

Tu peux très bien distribuer ton composant dans un fichier en l'attachant au scope global (comme jQuery par défaut), libre à l'utilisateur ensuite de l'attacher lui même au namespace de son appli.
 
 
Mais la véritable réponse à ce problème va être l'utilisation d'un module ES6. Chose que tu peux faire aujourd'hui en utilisant Ember App Kit, et très bientôt de base quand la conversion du code d'Ember sera finie.