バックグラウンド
私は、さまざまな種類の情報を管理し、EntitiesCollectionを拡張するジェネリックを定義するクライアント サーバー REST ベースのアプリケーションで作業していますBackbone.Collection。にEntitiesCollectionは、CRUD 操作、フィルタリング、並べ替えなどのための API (Backbone.Collection API を拡張したもの) があります。
私のチームは、オブジェクトを表示および操作できる Grid コンポーネントを作成する必要がありEntitiesCollectionます。このグリッドはサード パーティのコンポーネントに基づいており、使用を真剣に検討してKendo.Gridいます。
チャレンジ
私の最初の質問は、data\data-source が実際に Backbone.Collectionである Kendo.Grid を使用しようとしたことがある人がいるかどうか、そしてそれが適切で適切なアイデアであるかどうかです。
Derick Bailey のBackbone And Kendo UI: A Beautiful Combinationなど、 KendoとBackboneの統合に関するさまざまな記事を見てきました。ただし、これらの記事では、ビュー レベルの統合 ( を で囲む) について説明しています。私が探しているのは、データ レベルの統合です。Kendo.GridBackbone.ViewKendo.GridBackbone.Collection
オプション
私が理解している限り、これまでのところ、内部コレクションを保持するKendo.Grida で動作します- a 。Kendo.DataSourceKendo.ObservableArray
私たちがそれを目指していると仮定すると、いくつかの実装オプションがあります。
議論したオプションの 1 つは、 を に変換することですが
EntitiesCollection、Kendo.DataSourceこれはオプションではないようです。サーバーとの通信は、独自のオブジェクトを介して行う必要があります。Kendo.DataSourceをEntitiesCollection-に置き換えてEntitiesCollection、API を実装しKendo.DataSource、グリッドはそれを dataSource オブジェクトとして使用します。Kendo.DataSourceKendo がオブジェクトで提供する多くの機能が失われると思うので、この解決策は好きではありません。は
Kendo.DataSource私たち自身のリクエストをラップし、EntitiesCollectionそれにリクエストを委譲します。に含まれる
Kendo.ObservableArrayオブジェクトは、Kendo.DataSource私たちをラップしますEntitiesCollection(私がオンラインで見つけたこのサンプル実装を参照してください)。このアプローチは単純なユースケースで機能するように見えますが、何かが間違っているように思えます.リモートサーバーとやり取りしてデータを取得するのはオブジェクトであるため、 (剣道用語では)オブジェクトでBackbone.Collectionはなくオブジェクトだと思います.dataDataSource