3

Backbone を使用して、モデルのビューを作成しました。ユーザーに次のワークフローを提供したいと思います: a) 最初は、モデル コンテンツはテンプレートを介して表示されるだけで、編集ボタンがあります。b) ユーザーが編集ボタンをクリックすると、モデル コンテンツがフォームに表示され、保存ボタンをクリックすると、モデルに保存できます。c1) 正常に保存された場合、新しいモデル コンテンツがテンプレートを介して再レンダリングされ、再度表示されます。 c2) 検証エラーがあった場合、フォームはエラーで更新されます。

これを実装する方法について、次のオプションを思いつきました。しかし、ベストプラクティスについてはわかりません。どんなアドバイスでも大歓迎です。

オプション 1 : 2 つのサブビュー (コンテンツの表示用と編集用) は、表示と編集の間の切り替え時に動的に作成されます (その後ドロップされます)。

オプション 2 : 任意のスイッチ (トグルなど) で非表示/非表示にされる 2 つのサブビュー (コンテンツの表示用と編集用の 1 つ)

オプション 3 : 任意のスイッチの親要素に割り当てられた 2 つのサブビュー (コンテンツの表示用と編集用)。

オプション 4 : モデル コンテンツを管理するための 1 つのビューと、表示と編集の間の任意のスイッチでレンダリングされる 2 つのテンプレート (1 つは表示用、もう 1 つは編集用)。

私の直感では、すべてのロジックを処理できる 1 つのビューのみが必要になるため、明らかにオプション 4 を好みます。しかし、おそらく私はパフォーマンス、イベント処理、DOM アクセスなどの点で何かを見てきました。したがって、4 つのオプションの長所と短所に関する厳しい議論は高く評価されます。どう思いますか？

4

2 に答える 2

2

I have tried option 3 (2 subviews) and option 4 (1 view using 2 templates).

Here is an argument for 3:

Switching between readonly view and edit view in backbone js

And here is an article promoting 4, under "Switching a Contact Into Edit Mode":

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

I found option 3 to more trouble, because now you have 3 views using the same model. It brings up issues in the DOM, because now there is an el for the parent and an el for each child, nested inside. It also brings up issues with encapsulation, because the child views should really be inherited from the parent, but that's difficult with javascript:

Access parent class member with javascript inheritance?

I wanted option 3 to work more like an abstract base class tied to the el in the DOM. Then view and edit could inherit from it and internally set the el, preventing nesting of two els. But this breaks how backbone.js nests views:

Swap/switch/exchange backbone.js views in place?

Option 4 "just worked" the first time I tried it. It's trivial to have an editTemplate that gets rendered if View.editing is true. And in practice, the read-only view tends to be so small, with so little interaction by definition, that it only adds to an edit view by a few lines.

The downside to 4 is that you dirty your view with switching logic.

An argument for 4 is that it increases the possibility to reuse code and reinforce DRY.

One last argument for 4 is that you might have a "rich" form at some point that is always on, and maybe you only want to enable editing on specific form elements. For example a Contact form might have an Address view inside that handles its own updating. So view/edit might not be mutually exclusive down the road.

I finally resigned myself to going with what worked (option 4) because both options use two templates in the html file. The backbone.js implementation details don't matter to the end user.

I think this is all worthy of some lengthy articles weighing the pros and cons of each approach, with real-world examples. Backbone.js also needs to have backbone-relational built into it, and probably Backbone.ModelBinder, with a better ._super implementation. If some of these concepts were more fleshed out, it would make it easier to implement option 3 IMHO.

But I'm curious what others think, because neither 3 or 4 are perfect as they stand now, and I'd like to know what the best practices are for this, since form handling is one of the primary reasons that people get into backbone.js in the first place.

于 2013-01-25T20:25:06.360 に答える
2

編集ボタンがモデル全体ではなく、「その場で」編集できる個々の属性に関連付けられていることを除いて、私はこのようなことに取り組んできました。そのために、私はbackbone-formsを使用して、編集する要素をバックボーン フォームに置き換え、フォームが送信された後に再レンダリングしました。これは非常にうまく機能します。

あなたの場合、モデル全体を一度に編集しているので、実際には簡単です。ユーザーが編集ボタンをクリックすると、ビューがバックボーン フォームに置き換えられ、送信されたときに、モデル ビューがエラー メッセージまたは成功メッセージと共に再レンダリングされます。バックボーン フォームを使用すると、フォームにエラー メッセージを簡単に表示できます。

于 2012-08-12T22:19:52.920 に答える