Knockout 2.3.0 : binding
Callback, observable, la bibliothèque JavaScript UI de type MVVM se consolide
Le 2013-07-12 15:19:39, par vermine, Expert éminent sénior
Knockout 2.3.0 : binding, callback, observable
La bibliothèque JavaScript UI de type MVVM se consolide.
Knockout est une bibliothèque JavaScript qui permet de créer des interfaces utilisateur riches et dynamiques, ainsi qu'un éditeur d'interface utilisant un modèle de données sous-jacent. C'est une architecture MVVM (Modèle-Vue-VueModèle).
Avec cet outil, vous pouvez faire, par exemple :
Étant écrit en JavaScript pur, Knockout fonctionne avec n'importe quelle technologie serveur ou cliente. Elle peut donc être ajoutée à vos applications Web existantes sans nécessiter de modifications architecturales majeures. L'outil est d'ailleurs léger, environs 13 ko après compression.
Il fonctionne sur n'importe quel grand navigateur (IE 6+, Firefox 2+, Chrome, Safari, etc.).
Les développeurs familiarisés avec Ruby on Rails, ASP.NET MVC ou d'autres technologies de type MV* peuvent voir MVVM comme une forme en temps réel de MVC avec la syntaxe déclarative.
La version 2.3.0 vient de sortir. Elle propose notamment :
La bibliothèque JavaScript UI de type MVVM se consolide.
Knockout est une bibliothèque JavaScript qui permet de créer des interfaces utilisateur riches et dynamiques, ainsi qu'un éditeur d'interface utilisant un modèle de données sous-jacent. C'est une architecture MVVM (Modèle-Vue-VueModèle).
Avec cet outil, vous pouvez faire, par exemple :
- une mise à jour automatique des bonnes parties de votre interface utilisateur à chaque changement du modèle de données ;
- des liaisons déclaratives. C'est une façon simple et évidente pour relier votre interface utilisateur à votre modèle de données ;
- mettre en œuvre des comportements personnalisés comme de nouvelles liaisons déclaratives pour une réutilisation facile en seulement quelques lignes de code.
Étant écrit en JavaScript pur, Knockout fonctionne avec n'importe quelle technologie serveur ou cliente. Elle peut donc être ajoutée à vos applications Web existantes sans nécessiter de modifications architecturales majeures. L'outil est d'ailleurs léger, environs 13 ko après compression.
Il fonctionne sur n'importe quel grand navigateur (IE 6+, Firefox 2+, Chrome, Safari, etc.).
Les développeurs familiarisés avec Ruby on Rails, ASP.NET MVC ou d'autres technologies de type MV* peuvent voir MVVM comme une forme en temps réel de MVC avec la syntaxe déclarative.
La version 2.3.0 vient de sortir. Elle propose notamment :
- le renommage de hasfocus en hasFocus ;
- le paramètre name de template accepte les observables ;
- ko.unwrap ajoute un substitut pour ko.utils.unwrapObservable ;
- les options de binding utilisent la même technique que le foreach afin d'éviter des conversions inutiles ;
- l'ajout du callback optionsAfterRender afin de permettre un traitement personnalisé des options supplémentaires ;
- optionsCaption affiche une légende vide si la valeur est une chaîne vide.
-
stailerMembre chevronnéJ'utilise cette librairie depuis plusieurs mois et je ne peux plus m'en passer... Par contre, il y aura bien une modification architecturale majeure côté client (et même un peu côté serveur) :Elle peut donc être ajoutée à vos applications Web existantes sans nécessiter de modifications architecturales majeures
la méthode de dév n'a rien à voir avec du JQuery classique.
Si on utilise des composants (JQuery UI, Kendo UI, JQWidgets...) on retombera alors dans les travers du développement MVVM/Composants/Silverlight, à savoir :
Si tel ou tel composant n'est pas compatible knockout, il faudra alors :
- soit réaliser un handler pour qu'il le devienne ainsi que des petites modifications dans ce composant
- soit effectuer un petit bricolage côté code "classique" pour faire la liaison avec son ViewModel (ce que je fais parfois, j'avoue).
Bref, cette librairie est fantastique mais la migration d'une application existante en knockout prendra pas mal de temps et sera complexe selon moi.le 15/07/2013 à 11:23 -
stailerMembre chevronnéJe pense pas que la maintenance soit *2 comme tu le dis.
Quand tu parles de modifier les modèles, si tu veux dire : les mettre à jour par rapport à ta base de données, alors dans ce cas rien ne t'empêche de te faire une petite page avec le langage côté serveur que tu utilises, qui va régénérer automatiquement tes modèles à chaque fois que tu la lanceras.
Avec l'héritage, tu te feras des modèles qui héritent de ceux générés et comme ça tu seras toujours à jour.
Sinon oui, la couche modèle côté client se rajoute, je suis d'accord, mais c'est aussi un avantage. Tu vas pouvoir également stocker des méthodes dans tes modèles, utilisant leur données. Et tout ça va être bien structuré, bien "classé".
Bref, je pense qu'avec ce genre de framework on s'y retrouve bcp mieux et la maintenance est carrément plus claire et rapide.
On est pas pollué par du JQuery ou autres trucs de ce genre dans le code... On ne travaille que sur des propriétés de binding.
Personnellement depuis que je l'utilise tout s'est beaucoup simplifié pour moi.le 15/07/2013 à 14:53 -
negstekMembre confirméinconvénient de l'utilisation de ce framework, la maintenance applicative est multipliée par deux quand on veut faire évoluer son modèle, il faut aussi aller modifier le modèle javascript associé...le 15/07/2013 à 14:35
-
negstekMembre confirméJ'ai bossé dans une grosse équipe agile (+20 dev) sur un gros projet (gestion portuaire) et on a abandonné cette techno au bout de qq mois d'utilisation car justement ça a plus fini par nous ralentir qu'à nous aider. Les modèles devenait trop complexes, les bindings finissaient parfois par interagir les un entre les autres et comme je le disaient la maintenance était dupliquées.
Le concept est bien pensé, modifié les objets coté client en temps direct mais a utiliser si le besoin est vraiment adapté et à éviter pour les projets très volumineux.
J'en suis resté aux méthodes KISS et content no chrome.le 15/07/2013 à 15:20