Vue du modèle Backbone : Passage de l'édition (via le formulaire) à l'affichage

Question

Avec Backbone, j'ai créé une vue pour un modèle. Je voudrais fournir le flux de travail suivant aux utilisateurs : a) Initialement, le contenu du modèle est simplement affiché via un modèle et il y a un bouton d'édition. b) si l'utilisateur clique sur le bouton d'édition, le contenu du modèle sera affiché dans un formulaire et peut être sauvegardé dans le modèle en cliquant sur un bouton de sauvegarde. c1) si la sauvegarde est réussie, le nouveau contenu du modèle sera rendu à nouveau par le modèle et affiché à nouveau. c2) s'il y a eu des erreurs de validation, le formulaire est mis à jour avec les erreurs.

J'ai trouvé les options suivantes sur la façon de mettre en œuvre cette solution. Mais je ne suis pas sûr des meilleures pratiques. Tout conseil est le bienvenu.

Option 1 2 sous-vues (une pour l'affichage du contenu, une pour son édition) qui sont créées dynamiquement lors du passage de l'affichage à l'édition (et abandonnées ensuite).

Option 2 2 sous-vues (une pour l'affichage du contenu, une pour l'édition) qui sont cachées/décachées par n'importe quel interrupteur (comme une bascule).

Option 3 2 sous-vues (une pour l'affichage du contenu, une pour son édition) qui sont assignées à l'élément parent sur n'importe quel commutateur.

Option 4 : 1 Vue pour gérer le contenu du modèle et 2 modèles (un pour l'affichage et un pour l'édition) qui sont rendus lors de tout passage entre l'affichage et l'édition.

D'après mon intuition, je préférerais nettement l'option 4, car elle ne nécessitera qu'une seule vue qui pourra gérer toute la logique. Mais peut-être ai-je négligé quelque chose en termes de performances, de gestion des événements, d'accès au DOM, etc. Donc, tout argument solide sur les avantages et les inconvénients des 4 options est fortement apprécié. Qu'en pensez-vous ?

Answer 1

J'ai travaillé sur quelque chose comme ça, sauf que le bouton d'édition n'est pas attaché au modèle entier, mais à des attributs individuels, qui peuvent être modifiés "sur place". Pour ce faire, j'ai utilisé dorsale-formes en remplaçant l'élément à modifier par un formulaire dorsal, puis en le présentant à nouveau après l'envoi du formulaire. Cela fonctionne très bien.

Dans votre cas, puisque vous modifiez l'ensemble du modèle en une seule fois, ce serait en fait plus facile. Lorsque l'utilisateur clique sur le bouton d'édition, remplacez la vue par un formulaire Backbone, et lorsqu'il soumet le formulaire, présentez à nouveau la vue du modèle avec le message d'erreur ou de réussite. Les formulaires Backbone facilitent l'affichage des messages d'erreur sur le formulaire.

Answer 2

J'ai essayé l'option 3 (2 sous-vues) et l'option 4 (1 vue utilisant 2 modèles).

Voici un argument en faveur de 3 :

Passage de la vue en lecture seule à la vue en édition dans backbone js

Et voici un article promouvant le 4, sous "Passer un contact en mode édition" :

http://net.tutsplus.com/tutorials/javascript-ajax/build-a-contacts-manager-using-backbone-js-part-4/

---

J'ai trouvé l'option 3 plus problématique, car vous avez maintenant 3 vues utilisant le même modèle. Cela pose des problèmes dans le DOM, car il y a maintenant un el pour le parent et un el pour chaque enfant, imbriqués à l'intérieur. Cela pose également des problèmes d'encapsulation, car les vues enfant doivent être héritées du parent, mais c'est difficile avec javascript :

Accéder au membre de la classe parent avec l'héritage javascript ?

Je voulais que l'option 3 fonctionne plus comme une classe de base abstraite liée à l'el dans le DOM. Ensuite, view et edit pourraient en hériter et définir le el en interne, empêchant l'imbrication de deux el. Mais cela casse la façon dont backbone.js imbrique les vues :

Echanger les vues de backbone.js en place ?

---

L'option 4 a "fonctionné" la première fois que je l'ai essayée. Il est trivial d'avoir un editTemplate qui est rendu si View.editing est vrai. Et en pratique, la vue en lecture seule tend à être si petite, avec si peu d'interaction par définition, qu'elle n'ajoute que quelques lignes à une vue d'édition.

L'inconvénient du 4 est que vous salissez votre vue avec une logique de commutation.

Un argument en faveur de 4 est qu'il augmente la possibilité de réutiliser le code et de renforcer le DRY.

Un dernier argument en faveur de l'option 4 est qu'il se peut que vous ayez un formulaire "riche" qui est toujours actif et que vous ne souhaitiez activer l'édition que sur des éléments spécifiques du formulaire. Par exemple, un formulaire de contact peut contenir une vue d'adresse qui gère sa propre mise à jour. Ainsi, l'affichage et l'édition pourraient ne pas s'exclure mutuellement à l'avenir.

---

J'ai fini par me résigner à choisir ce qui fonctionnait (option 4), car les deux options utilisent deux modèles dans le fichier html. Les détails de l'implémentation de backbone.js n'ont pas d'importance pour l'utilisateur final.

Je pense que tout cela mérite de longs articles pesant le pour et le contre de chaque approche, avec des exemples concrets. Backbone.js doit également intégrer Backbone-relational, et probablement Backbone.ModelBinder, avec une meilleure implémentation de ._super. Si certains de ces concepts étaient plus étoffés, il serait plus facile de mettre en œuvre l'option 3, à mon avis.

Mais je suis curieux de savoir ce que les autres en pensent, car ni la version 3 ni la version 4 ne sont parfaites en l'état actuel des choses, et j'aimerais savoir quelles sont les meilleures pratiques en la matière, puisque la gestion des formulaires est l'une des principales raisons pour lesquelles les gens se lancent dans backbone.js en premier lieu.