Reprise du message précédent :

Tu veux faire quoi en fait ?

un champ qui côté HTML est un type=number et coté javascript ne travaille qu'avec des nombres, pas avec des chaînes.

(je suppose que c'est super-simple, mais j'y arrive pas )

C'est pas suffisant ça  ?

http://emberjs.jsbin.com/cisewiqira/1/edit

Développement open source sous Windows, tu as bien du courage Mon premier conseil serait de changer ça. ( et ce n'est pas un problème unique à Ember.js ). Dès que tu as des outils liés à la manipulation de fichiers, ca devient pénible ( j'avais eu le même problème avec RoR ).

Sinon as tu lu cet article de blog : http://emberjs.com/blog/2015/02/05 [...] -10-0.html

qui mène entre autre à ça

et ça

https://gist.github.com/tomaskikuti [...] 5ce580b1f7

et sous forme de composant ré-utilisable ?

Après 2 secondes de recherche, je trouve ça pour gulp et htmlbars

https://www.npmjs.com/package/gulp-htmlbars

et ça

https://gist.github.com/tomaskikuti [...] 5ce580b1f7

 
JsBin mis à jour
 
http://emberjs.jsbin.com/cisewiqira/1/edit

ok, merci, il va falloir que je démerde le merdier pour mon cas.

en fait j'ai pas posé la bonne question. Est-ce que tu l'as sous forme de sous-classe de TextField stp ?

Ca va être un poil plus compliqué.

{{input}} est un helper qui, par défaut, va créer un composant TextField.

https://github.com/emberjs/ember.js [...] t_field.js

Ca veut dire que pour garder la syntaxe {{input type="number"}} il faut jouer avec le helper et ajouter un nouveau cas ( comme c'est fait pour checkbox )

https://github.com/emberjs/ember.js [...] s/input.js

Faut que je fasse mumuse qqs minutes.

T'es toujours sous Ember 1.5?

ember 1.7

Nouvelle version
 
http://emberjs.jsbin.com/cisewiqira/2/edit
C'est un peu cracra la manière dont je redéfinis `attributesBinding`, mais ca marche.
 
Le truc important c'est  

pour créer le niveau d'indirection permettant la conversion.
 
J'ai aussi défini un nouvel helper `my-input` pour gérer le cas `type="number"` séparément.
 
Ca colle mieux à tes besoins ?

yep, merci, un rapide test montre que ça marche, je suis en train d'étendre à toute l'appli.

merci, c'est intégré. Ironiquement c'est pas plus court en lignes de code, mais le mécanisme est mieux je trouve.

Je me demande si ca pourrait faire l'objet d'une PR un truc comme ça

ça sent la merde avec les Nan et les infinis, pour l'instant j'ai fait l'autruche sur cette partie.

J'ai fait au plus simple. Il y a clairement des trucs à gérer en plus
 
Tu dois pouvoir gérer ces cas dans `fieldValue`

nan, mais aussi côté interface, comment saisir et représenter les infinis.
souvent même pour les interfaces, il vaut probablement mieux traduire l'infini en un truc métier genre un checkbox "no limit" que de permettre de le saisir directement.

(e si t'es *vraiment* pédant, tu peux gérer le zéro signé aussi)

Je vais avoir d'autres trucs à faire de mon dimanche je crois

je suis assez d'accord. Je pense que ça explique pourquoi le W3C l'a pas fait.

edit: la formulation était artistiquement intéressante, mais ça voulait quand même rien dire.

 
Vu aussi, mais vu la syntaxe de replace ('export default'), je suppose que c'est AMD obligatoire uniquement.
 

 
Oups, j'ai zappé ça    
 

 
Du coup tu as tout a fait raison    
 
Le fait de ne pas vouloir d'ES6 ES2015, ca va te compliquer la tâche pour trouver quelque chose. Gulp n'est pas l'outil le plus utilisé dans la communauté AMHA, ce qui va d'autant plus limiter ton choix. Et ensuite il y a le cas Windows...
 
 
Il y a eu plusieurs PRs associées à Windows mergées dans Ember CLI depuis le début de l'année ( https://github.com/ember-cli/ember- [...] =%E2%9C%93 ), tu rencontres quoi comme problème ?
 
 
Je vais peut être bouffer avec Stefan Penner cette semaine, il vient de se faire embaucher par Yahoo!, et il va être payé à améliorer Ember CLI. Je vais voir avec lui ce qu'il en est de la version Windows.

en fait après tests, ça marche pas.
dans le JSBin, si tu change la valeur de 12 à 13 avec le clavier (c'est important), le type passe à string.

Disclaimer : c'est moins un question Ember que de modélisation.
 
J'ai une donnée qui correspond à une heure de rendu pour un livrable donné. Côté serveur, je stocke un datetime puisque ce rendu s'effectue à une date donnée, l'utilisateur ne doit cependant avoir la main que sur l'heure (mm:ss).
 
Côté modèle Ember :
A. DS.attr('string') et comme ça je ne me prend pas la tête pour l'édition, on règlera la mise en cohérence date / heure côté serveur
B. DS.attr('date'), je n'affiche que la partie time mais dans ce cas je ne vois pas comment traiter la bascule automatique de date (édition de 23:42 vers 00:12 => date + 1)
C. Autre chose que je ne vois pas (Profit!)
D. Obiwan
 
Si vous avez des idées sympa pour l'édition par l'utilisateur, je prend également.

En générale, j'essaie de raisonner en terme d'API.
 
Tu as une date et une heure. Je renverrais donc le datetime ( car l'appli qui la consomme peut décider de tout afficher ).
 
Pour la mise à jour de l'heure, il suffit de retourner une erreur si la partie date est modifiée.

 
Ce que j'essayais d'exprimer, c'est le fait que lorsqu'un utilisateur saisi 01:01 alors que la précédente valeur affichée (on ne montre que l'heure) était avant minuit, le datetime doit être mis à jour avec la nouvelle heure mais également à date + 1. Ça se fait dans le controller je présume, ma question était plutôt de savoir si c'était pertinent et si éventuellement le boulot n'avait pas déjà été fait.
 

C'est un problème d'UX j'ai l'impression. Tu ne vas pas pouvoir utiliser un simple input, il faut que l'utilisateur puisse faire + ou -, ce qui te permet de détecter le changement de jour.
 
Je ne suis pas sur de bien saisir ta question. Il semble que l'utilisateur a moyen de changer le jour ( mais pas forcément directement ).

C'est effectivement l'UX qui va déterminé la manière dont je vais l'implémenter.
 
Il est 23h00. L'utilisateur a devant lui un listing des livrables des prochaines 12h (par exemple). Pour chacun, on affiche l'heure de rendu prévisionnelle, un date dont on affiche que la composante time.
L'utilisateur peut éditer cette heure, et si il est 23h, que l'heure de rendu est à 23h30 et qu'il la modifie vers 00h17, c'est bien qu'il décalle la date de rendu à demain.
Derrière, il faut donc que dans ce cas le modèle détecte qu'il y a changement de jour consécutif au changement d'heure.
 
Je sais toujours pas si je suis clair
je vois comment faire hein, donc t'embête pas, je posais la question parce qu'il pouvait y avoir de bonnes idées.

Je suis plussoie Youmoussa : ta donnée est de type datetime, donc ton api doit exposer et consommer un champ de type datetime. La manière dont ce champ est modifiable par l'utilisateur est un problème d'UX et ne doit pas interférer avec la spécification de l'API.

Ember data, j'aimerais que les requêtes vers mes objets de modèles soient hyphénisées plutôt que camel case.

models/foo.js :

export default DS.Model.extend({
    type: DS.belongsTo('foo-type'),    
});

models/foo-type.js est défini également.

Quand je charge un Foo :

J'aimerais que l'URI soit /api/foo-types/1. Y'a un moyen simple de faire ça (et tant qu'à faire rendre se comportement globale à l'application) ? Je vois rien dans le RESTAdapter à ce sujet.

Edit : apparemment un bug dans Ember Data (ember-data#2318), avec un workaround ici

C'est quoi la manière idiomatique de copier un array provenant du modèle (DS.hasMany('bar') dans le modèle foo) ?
 
Dans un template, j'utilise :

et je souhaiterais ensuite itérer sur le reste des éléments (soit foo.bars moins la première valeur).
 

Une computed property ?

export default DS.Model.extend({
    type: DS.belongsTo('foo-type'),    
});

 
 
Surcharge pathForType au niveau de l'adapter
 
https://github.com/emberjs/data/blo [...] in.js#L252

 
Tu veux avoir 2 tableaux différents à la fin ou que foo est une référence vers bars ?

Je devrais lire plus attentivement

Tryptique va dans la bonne direction du coup

Tu peux utiliser firstObject pour la première et slice ( http://emberjs.com/api/classes/Emb [...] thod_slice ) pour la 2ème

OK, c'était slice qui me manquait. J'étais un peu paumé entre Array, ArrayProxy et du JS conventionnel.
 

Avec l'input helper, les noms d’événements doivent être dasherisés :

En utilisant le helper action, seul le camelCase fonctionne :

 
WTF?

C'est quoi le ember way pour avoir des slugs dans les url et communiquer avec des IDs dans les appels à l'api backend ? (j'utilise ember-data).

 
Serialize au niveau de la route
 
http://emberjs.com/api/classes/Emb [...] _serialize
 
http://guides.emberjs.com/v1.10.0/ [...] ur-routes/

 
J'ai pas le temps de vérifier, mais ça ressemble à un bug du input helper