Reprise du message précédent :
bouarf, moi je suis en cowboy dépressif tout seul à la maison, donc la notion de sprint c'est mort.
 
par contre, ça vaudrait peut-être le coup de mettre un lien vers une page dans les warnings de dépréciation, c'est parfois un peu ardu à capter.

ouch, trouver un tuple de versions compatibles entre elles pour ember, ember-data, ember-precompile (et donc une version de node.js) et ember-fire ça a l'air compliqué.
 
Je veux bien changer mon code pour suivre la mode, mais là ça sent plus le DLL hell que simplement suivre une série de warnings et aller chercher dans les notes de migration la ligne qui va bien.

hum, on dirait que ember-precompile est coincé à Ember 1.7, et quand je mate la doc de ember-cli ça a l'air d'être une énorme usine à gaz big-bang, il me faudrait lire des docs pendant des heures pour simplement l'utiliser comme j'utilisais ember-precompile, sachant qu'il y a toute la montée de version de firebase à faire de l'autre côté et je dois changer d'IDE au passage. j'ai pas le courage de faire ça.

 
Ben si tu codes ton appli proprement
 
L'appli a commencé à être développée avant la version 0.9 si je ne m'abuse, les conventions étaient loin d'être établies à l'époque.
Et comme ils ont pas essayé de mettre à jour fréquemment, je me retrouve à devoir le faire avec une énorme appli que je ne maitrise pas entièrement.

Je ne me rends plus compte tellement on est en retard

Théroriquement, le problème est connu et c'est pour ça que Ember, Ember Data, Ember-CLI et ListView ont des numéros de versions communs désormais.

Je ne sais pas à quel point les mecs de Firebase suivent le projet, je sais qu'ils étaient un peu à la ramasse il y a 1-2 ans.
On est en train de finaliser la migration vers Ember-CLI, c'est un gros point positif pour moi.

Si j'avais plus de temps, j'aimerais bien t'aider plus.

moi j'ai aucune confiance qu'Ember-cli m'aidera réellement. Vu toutes les merdes et toutes les contraintes entre lesquelles je dois me faufiler (la sandbox de chrome, les workers, l'interdiction de bloquer le thread central sous peine de niquer la pièce, l'absence de serveur web dynamique), j'ai aucune chance qu'un système big-bang corresponde à mon usage out-of-the-box, et je vais devoir comprendre parfaitement tous les détails pour le tordre à mes volontés. Plus le système est gros et plus ça va être long de lire la doc et le source.

Non mais Ember-CLI, c'est en gros un build tool. Ca va se charger de compiler les templates pour toi. La seule chose que je ne sais pas/plus, c'est si le code généré serait compatible avec ton utilisation, et de prime abord, je ne vois pas de problèmes.

https://gist.github.com/tim-evans/5783095  
good ? pas good ?

http://emberjs.com/blog/tags/releases.html
y'a un endroit où y'a toutes les releases ? je cherche un chemin de migration (je suis en 1.7, DS en 1.0.0-beta.11), mais j'arrive même pas à trouver la liste des releases sur le site.

edit: trouvé http://emberjs.com/builds/#/tagged

 
Ça me chagrine de voir du copier/coller de setUnknownProperty.
 
Je ne sais pas au premier abord s'il y a moyen de faire mieux. Je chercherais plutôt à voir si la machine d'état interne envoie un événement.

Vos backends sont sous quelles technos ?
 
Historiquement, on est en Java avec Spring mais depuis l'arrivée du JSON API Adapter par défaut dans la branche 2 d'Ember, on a regardé du côté de Katharsis et Elide mais les paradigmes changent assez violemment.
 
Si on doit prendre le virage JSON API (doit-on le prendre d'ailleurs ?), on voit deux solutions : soit on change uniquement la couche de serialization/deserialization back et on continue de faire du N-tiers à papa, soit on part vers les FW cités plus haut, full HATEOAS, mais en faisant complètement abstraction de l'existant. Même si ces derniers sont plugables à des applis "historiques", ça parait assez casse-gueule et contre-productif.
 
En dehors de l'écosystème Java, je suis curieux de savoir comment (et si) vous avez effectué cette transition.
 
J'ai d'autres débats sous le coude (architecture pods, orientation en components...) mais on va déjà tenter de doucement réanimer le topic

On est en pleine discussion sur ce sujet, sachant qu'on construit aussi une API publique, avec un back end en Java.
 
J'ai clairement vécu dans le passé les discussions sans fin sur le format retourné, donc j'aime l'idée de suivre un standard. Le problème c'est que c'est nouveau, donc c'est dure d'appeler ca un standard au niveau de l'industrie, mais ca nous donne une opportunité d'y contribuer si besoin.
 
Parmi les craintes qu'on a:
- l'utilisation de PATCH
- l'utilisation de header
- verbosité  
On regarde aussi le coût de développer/maintenir des adapteurs/serialiseurs pour différents langages.
 
J'ai rendez vous avec un mec aujourd'hui qui a fait ce choix pour leur API publique.

Je suis intéressé par ton retour.
 
La question que je me pose quand je regarde des FW comme Elide, c'est sur la responsabilité du métier qui me semble être déporté vers le front.
 
J'ai l'impression qu'à part du contrôle des cohérence de données en fonction des entités annotées, je perds la main sur ce que l'ont mettais dans la couche de service. L'API deviendrait un simple passe-plat vers la couche de persistance sans aucune autre logique métier ni niveau de contrôle.

Tu as du nouveau sur ce sujet JON API et back Java ? C'est toujours en gestation de mon côté.
Voir sinon le crosspost sur le topic Java.

On est parti avec Katharsis. J'ai moins suivi le projet en cette fin d'année, je vais demander des retours.

Live stream d'EmberConf
 
https://t.co/9xlPD8Fr9N

Tu peux leur dire de mettre le planning des talks sur la page youtube ? C'est pas pratique de devoir aller chercher le schedule sur http://emberconf.com
Ou alors un texte genre "Next talk: XXX by AB CD at hh:mm" sur le stream directement.
 
C'est moi où ils ont une presque une heure de retard ? Là y a le talk "Going progressive with ember" qui vient de commencer, alors qu'il est annoncé à 10:45 sur emberconf.com

Yehuda s'est un peu raté sur la durée de la Keynote

J'ai demandé pour le mettre le schedule, on va voir si ça passe

La grosse annonce de la Keynote est la possibilité de faire du Ember en version allégée  
 
https://glimmerjs.com/

Ember 3.0 est disponible.
 
EmberConf 2018 a lieu la semaine prochaine.

T'as une exclu sur la grosse annonce de cette année ?

nope
 
Je sais qu'il y a eu beaucoup d'investissements dans Glimmer 2 et les engines. LinkedIn sponsorise/embauche beaucoup dans cette direction.

et avec le process RFC, c'est généralement plus transparent ce qui va être livré https://github.com/emberjs/rfcs

EmberConf 2019 en ligne de mire.
 
Ember Octane est la prochaine grosse release, avec beaucoup de nettoyage et d'avancées.
 
La communauté a basculé de Slack vers Discord https://github.com/emberjs/rfcs/pull/345
Il y a un canal pour les francophones, n'hésitez pas à poser vos questions.

Discord

Ember.js project se lance dans le marketing, "Ember.js: The Documentary"
 
https://thenextweb.com/dd/2019/02/2 [...] ally-good/

je suis en train de modifier une app qui sur ember 1.7.0 avec ember-data sur 1.0.0-beta.11.
 
le storage adapter était firebase, mais c'est mort, je voudrai convertir le storage en localstorage.
 
1) est-ce que c'était inclus avec ember-data ? ou est-ce que je dois faire mon adaptateur (et comment où trouver la réponse)
2) comment je trouve la liste des fonctions à implémenter si je dois faire mon adaptateur moi-même ?

je viens de trouver ça: https://github.com/locks/ember-loca [...] ckage.json mais je sais pas trop comment trouver la version qui irait avec ma stack.

je doute que ca marche, mais j'ai pas en tête les changements entre beta 11 et beta 15. Ca coute rien d'essayer.

Pour savoir comment implémenter un adapteur, tu peux te baser sur la documentation du code source : https://github.com/emberjs/data/blo [...] #L100-L109

https://github.com/emberjs/data/blo [...] adapter.js

Il y a des informations sur chaque méthode dans ce fichier.

Ember Octane est officiellement disponible  
 
https://blog.emberjs.com/2019/12/20/octane-is-here.html
 

 
Grosse évolution, avec abandon entre autre de `Ember.Object` et l'utilisation à la place des classes JS de manière native.
 
C'est beaucoup plus simple à apprendre et à utiliser.

Pour info, les versions web des derniers gros services Apple tel Apple Music sont développés avec Ember.js

merci.
J'ai avancé un peu, j'ai importé le truc trouvé sur github plus haut, mais j'ai un problème un peu plus technique, il a pas l'air de sérialiser mes hasMany embedded.

J'ai un modèle Job:

j'en créé un et je lui met des shapes et je le sauve, quand je reloade, les shapes sont plus là.
sauvegarde de Job:

à ce point:
 https://github.com/locks/ember-loca [...] er.js#L240
l'objet retourné n'a pas de champ shapes.

et il est jamais passé dans cette fonction: https://github.com/locks/ember-loca [...] pter.js#L8

edit: j'ai trouvé, c'était à moi de déclarer leur serializer dans mon application: