Archives par mot-clef : mvc

Il y a quelques jours, je partageais avec vous mes impressions sur AngularJS. C’est au tour d’EmberJS comme promis. J’ai pu tester le développement d’une même application avec ces deux frameworks mis en concurrence. Le vrai positif Le développement avec Ember est intéressant en soit. Nombre de concepts pratiques au développement d’applications riches y sont inclus et on peut donc s’appuyer tranquillement sur ses composants. Le modèle MVC est bien intégré à l’architecture du projet, le binding plutôt réactif, possibilité de faire des propriétés dynamiques via le modèle pour les vues (équivalent des filtres AngularJS). Là où ça pique Le hic, c’est justement de ne reposer que sur ses composants. J’ai beau avoir fouillé, lu, décortiqué, lire le code d’un framework n’est pas suffisant pour en comprendre la philosophie et du même coup construire une application avec. Vous l’aurez compris, le gros … Continuer la lecture

J’ai promis de faire un état de l’art, il y a quelques jours sur Twitter, des frameworks JS. Et finalement, je suis tombé sur Throne of JS. Une conférence qui s’est tenue à Toronto en juillet. L’idée était « d’opposer » 7 frameworks majeurs du monde du JS et plus précisément : Backbone ; Ember ; Knockout ; Spine ; CanJS ; AngularJS ; Batman ; Meteor. (oui, ça fait 8 et alors ?) Et surtout, je suis tombé sur un compte-rendu très complet, réalisé par un des orateurs pro-Knockout (membre de la core team d’ailleurs). Je vous invite à le lire, c’est vraiment très complet et intéressant.

Ce matin, j’annonçais sur Twitter avoir mis en place un projet NodeJS basé sur une architecture/pattern MMVC. Suite aux questions reçues, il semble nécessaire d’expliquer ce que c’est. Avantages et inconvénients. MMVC ? Pour Model – ModelMapper – View – Controller. C’est un dérivé du design pattern classique MVC adapté au travail avec les bases de données. Reprocher des choses au MVC Le modèle classique du MVC part d’un bon fondement : déléguer les responsabilités à des éléments séparés. Les données d’un côté, l’affichage d’un autre et un élément central pour faire le lien. Le problème de ce pattern, c’est que la gestion des données implique aussi bien : Les fonctionnalités métier. Par exemple, peindre ma voiture veut dire que je change la valeur de la propriété couleur de l’objet voiture ; La synchronisation avec la source de données. Par … Continuer la lecture

Truc bête, quand je me suis mis à Ember.js, j’ai rencontré un souci bête et méchant qui donnait ça : Alors que je voulais ça : L’astuce vient de la façon de déclarer vos templates. Quand vous voulez mettre en place un tableau de données dynamique, les balises script doivent encadrer le tableau et non encadré la ligne tr de modèle. Ainsi, il ne faut pas faire : <div> <h1>Dernières propositions</h1> <table class="basic" cellspacing="0"> <script type="text/x-handlebars"> {{#collection contentBinding="App.myController" tagName="tbody" itemViewClass="App.myView"}} <th>{{content.date}}</th> <td class="full">{{content.name}}</td> <td><img src="images/ball_{{content.couleur}}_16.png" alt="" title="Online User"></td> {{/collection}} </script> </table> </div> Mais bien : <script type="text/x-handlebars"> <div> <h1>Dernières propositions</h1> <table class="basic" cellspacing="0"> {{#collection contentBinding="App.myController" tagName="tbody" itemViewClass="App.myView"}} <th>{{content.date}}</th> <td class="full">{{content.name}}</td> <td><img src="images/ball_{{content.couleur}}_16.png" alt="" title="Online User"></td> {{/collection}} </table> </div> </script> Et là tout de suite, ça marche mieux 😉 Le tagName permet d’indiquer dans quel région du tableau doit se situer … Continuer la lecture

Une revue point par point du développement de jQuery Mobile. Continuer la lecture