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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Ember 1.8.0 : en route vers HTMLBars
Pour le framework JavaScript permettant de créer des applications Web

Le , par vermine

22PARTAGES

1  0 
Ember 1.8.0 : en route vers HTMLBars


Ember.js est un framework JavaScript permettant de créer des applications Web ambitieuses !

En utilisant des templates intégrés, vous écrivez considérablement moins de code et vos pages se mettent à jour automatiquement lorsque les données sous-jacentes changent. Il n'est pas nécessaire de réinventer la roue car Ember.js intègre des expressions idiomatiques courantes.

La sortie de la version 1.8.0.

Dans les versions précédentes, le code HTML d'une page est créé (via Handlebars) et assemblé (via l'affichage de l'arbre) en utilisant la concaténation de chaînes. Dans Ember.js 1.8, les parties d'une page sont toujours créées sous forme de chaînes de caractères mais sont ensuite analysées et assemblées sous forme d'arbre DOM. Cette nouveauté porte le nom de metal-views et est un premier effort d'implémentation de HTMLBars (un compilateur pour Handlebars qui génère un arbre DOM plutôt qu'une chaîne de caractères).

Les bénéfices sont :

  • la suppression de la récursivité de la couche d'affichage. Cela améliore le travail du garbage collector pendant l'affichage et permet la réutilisation des objets au cours de l'affichage ;
  • l'amélioration des espace de noms HTML. Cela introduit la prise en charge des composants, de la liaison de données et de la logique inline des documents SVG ;
  • le remplacement des balises <script> comme dans l'exemple suivant :
    Code html : Sélectionner tout
    1
    2
    3
    <script id="metamorph-1-start" type="text/x-placeholder"></script> 
    Bob 
    <script id="metamorph-1-end" type="text/x-placeholder"></script>
    Elles sont parfois gênantes. Le moteur a été ré-écrit et utilise les nœuds de texte vide (morph.js).


Pour le reste des modifications apportées par cette nouvelle version, il y a l'éternel combat qui est d'améliorer les performances. C'est le cas notamment par l'ajout de caches pour les opérations qui manipulent des chaînes de caractères qui dovient avant tout être normalisées. Mais aussi par le support des mises à jours du moteur V8 ou bien des navigateurs.

Notons également quelques dépréciations :

  • la classe Ember.Set qui n'est pas compatible avec les nouvelles normes ;
  • dans Ember.Map, la méthode delete remplace la méthode remove ;
  • currentWhen devient current-when ;
  • etc.


Remarque : l'équipe tente de rester compatible dans ses révisions mineures mais doit parfois faire des changements qui peuvent avoir un impact sur votre code actuel.

Vous trouverez la liste complète des nouveautés et corrections ici.

C'est également l'occasion pour l'équipe d'annoncer la sortie de la version bêta 1.9.0.

Télécharger.
L'annonce officielle.
La documentation.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 30/10/2014 à 17:30
On dirait que tous les gros frameworks JS du moment (Angular, Ember, Meteor) misent sur leur couche de data-binding, alors que c'est censé être la couche superficielle d'un framework. J'aurais préféré que cette couche soit interchangeable ou distribuée séparément. Mais bon, qui dit framework dit moins de liberté de choix.
2  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 13/11/2014 à 9:57
Ca tombe bien j'ai travaillé sur différents types d'applications (domaine métier, infrastructure, etc), notamment du Web, du client lourd et du RCP. Je n'ai aucun partie pris, chacun a ses avantages et inconvénients.

Mais dire que les "applications Web" (et plus globalement les "plateformes clients", RCP inclus) n'ont pas d'utilité, c'est en revanche un discours sur lequel je ne suis pas d'accord (On est d'accord sur le fait qu'on a chacun nos opinions ).

Je vois mal un client téléchargé manuellement l'application de chaque "site" qu'il visite : Facebook, Twitter, Amazon, etc. Pourtant c'est bien ce qu'il se passe derrière grâce "à la magie" du Web. Comparé le déploiement d'un client lourd à celui d'une application Web, c'est simplement méconnaître le problème.

Surtout depuis l'arrivée de Windows Vista (et cela s'applique également à Linux) dès lors qu'on veut une installation commune à plusieurs utilisateurs. Sinon la solution d'installer sous "HOME" fonctionne bien. La télédistribution que tu évoques fonctionne qu'en partie en entreprise mais n'est absolument pas une solution sous Android/iOS (pour Mac OS, je ne sais pas) et encore moins pour un particulier.
Même s'il existe les stores, les clients sont libres de se mettre à jour ou pas. C'est déjà la galère de gérer un parc matériel étendu, alors logiciel j'en parle même pas.

Vu la galère que c'est pour gérer des patchs, la plupart des applications reposent sur la réinstallation "par dessus" ou à côté pour gérer les mises à jour. Et la plupart nécessite de tout faire manuellement (téléchargement, installation).

Enfin tout le monde possède un navigateur, c'est moins vrai d'une plateforme RCP.
1  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 12/11/2014 à 23:38
C'est bien le principe des "applications Web" !
L'avantage indéniable concerne la distribution. La maintenance et le contrôle des versions en est grandement simplifié, puisque tout le "logiciel" (binaire et/ou source) est centralisé.

L'autre avantage repose sur l'ensemble des standards qu'offre un navigateur : HTML, JS, CSS, HTTP, URL, Web component, Offline, etc. Clairement les navigateurs deviennent des RCP.
Le tout étant disponible (en partie) sur toutes les plateformes : Windows, Mac, iOS, Linux, BSD, Solaris, PC, tablette, smartphone, etc.
0  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 13/11/2014 à 11:19
Il n'y a pas de comparaison possible entre une boîte de dev comme Qt Software et un consortium international comme le W3C...
0  0 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 13/11/2014 à 8:18
Citation Envoyé par Logan Mauzaize Voir le message
C'est bien le principe des "applications Web" !
L'avantage indéniable concerne la distribution. La maintenance et le contrôle des versions en est grandement simplifié, puisque tout le "logiciel" (binaire et/ou source) est centralisé.
Windows et Linux font déjà ça depuis des années, sinon le déploiement sur un parc avec des centaines de machines

Citation Envoyé par Logan Mauzaize Voir le message
L'autre avantage repose sur l'ensemble des standards qu'offre un navigateur : HTML, JS, CSS, HTTP, URL, Web component, Offline, etc. Clairement les navigateurs deviennent des RCP.
Le tout étant disponible (en partie) sur toutes les plateformes : Windows, Mac, iOS, Linux, BSD, Solaris, PC, tablette, smartphone, etc.
Ce ne sont que des "guidelines". Rien n'est imposé, et si on veut faire n'importe quoi, on peut parfaitement. Clairement, les navigateurs reprennent ce que fait l'OS. C'est juste débile. Mais bon on a l'impression de faire quelque chose de nouveau, c'est ça qui plait en général chez les informaticiens : la nouveauté.

Question multiplateforme, QT fait ça aussi depuis des années, et largement mieux que le monde bordélique du Web. Bref, tous ceux qui ont eu l'expérience avant, sans le Web, et maintenant, avec, me comprennent et sont tous d'accord - jamais quelqu'un qui a développé quelques années sur Windows /et/ou Linux ne m'a contredit - et tous ceux qui n'ont pas eu l'expérience - ou peu - "d'avant" le Web, sont intimement convaincus que c'est la voie à suivre. Donc je ne vais essayer de convaincre personne, je sais que je n'y arriverai pas...
0  1 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 09/11/2014 à 23:20
Citation Envoyé par SylvainPV Voir le message
On dirait que tous les gros frameworks JS du moment (Angular, Ember, Meteor) misent sur leur couche de data-binding, alors que c'est censé être la couche superficielle d'un framework. J'aurais préféré que cette couche soit interchangeable ou distribuée séparément. Mais bon, qui dit framework dit moins de liberté de choix.
Moi ce qui me fait marrer c'est le fait de réinventer la roue. D'ici quelques années on aura quelque chose qu'on n'a jamais vu : un bureau, avec des fenêtres, un Word, un Excel, la gestion de mail, et des applis qui font du data-binding... ah mais ça existe déjà ! Oui mais là ça sera dans un navigateur. Waaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhh

Et dites moi quelle différence ça fera pour un utilisateur "basique", entre une fenêtre mode "web" et une fenêtre sur Linux ou Windows ? Bah aucune, si ce n'est que ce sera juste moins agréable... et le pire c'est que ça existe déjà (cf le l'interface Web de connexion Freebox...)

Bon on est toujours très très loin de création d'une application totale full Windows, databindé et datagrid avec .net ou Delphi en moins de deux minutes...
0  2