バックグラウンド
私は、さまざまな種類の情報を管理し、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.Grid
Backbone.View
Kendo.Grid
Backbone.Collection
オプション
私が理解している限り、これまでのところ、内部コレクションを保持するKendo.Grid
a で動作します- a 。Kendo.DataSource
Kendo.ObservableArray
私たちがそれを目指していると仮定すると、いくつかの実装オプションがあります。
議論したオプションの 1 つは、 を に変換することですが
EntitiesCollection
、Kendo.DataSource
これはオプションではないようです。サーバーとの通信は、独自のオブジェクトを介して行う必要があります。Kendo.DataSource
をEntitiesCollection
-に置き換えてEntitiesCollection
、API を実装しKendo.DataSource
、グリッドはそれを dataSource オブジェクトとして使用します。Kendo.DataSource
Kendo がオブジェクトで提供する多くの機能が失われると思うので、この解決策は好きではありません。は
Kendo.DataSource
私たち自身のリクエストをラップし、EntitiesCollection
それにリクエストを委譲します。に含まれる
Kendo.ObservableArray
オブジェクトは、Kendo.DataSource
私たちをラップしますEntitiesCollection
(私がオンラインで見つけたこのサンプル実装を参照してください)。このアプローチは単純なユースケースで機能するように見えますが、何かが間違っているように思えます.リモートサーバーとやり取りしてデータを取得するのはオブジェクトであるため、 (剣道用語では)オブジェクトでBackbone.Collection
はなくオブジェクトだと思います.data
DataSource