背景
我正在一个基于客户端-服务器 REST 的应用程序中工作,该应用程序管理各种信息并定义了一个EntitiesCollection
扩展Backbone.Collection
. 它EntitiesCollection
有一个用于 CRUD 操作、过滤、排序等的 API(它扩展了 Backbone.Collection API)。
我的团队需要编写一个可以显示和操作EntitiesCollection
对象的 Grid 组件。该网格将基于一些 3rd 方组件,我们正在认真考虑使用Kendo.Grid
.
挑战
我的第一个问题是,是否有人曾尝试使用其 data\data-source 实际上是 Backbone.Collection 的 Kendo.Grid,这是否是一个好的和适用的想法?
我看过各种关于Kendo和Backbone集成的文章,包括 Derick Bailey 的Backbone And Kendo UI: A Beautiful Combination。但是,这些文章讨论了视图级别的集成(Kendo.Grid
用 a包装Backbone.View
)。我正在寻找的是数据级集成 -Kendo.Grid
与Backbone.Collection
.
选项
据我所知,到目前为止,它Kendo.Grid
与 a 一起工作,Kendo.DataSource
而后者又拥有一个内部集合 - a Kendo.ObservableArray
。
假设我们要这样做,我会看到几个实现选项:
我们讨论的选项之一是将我们的转换
EntitiesCollection
为 aKendo.DataSource
但这似乎不是一个选项 - 与服务器的通信必须通过我们自己的对象完成。替换为
Kendo.DataSource
-EntitiesCollection
我们EntitiesCollection
将实现Kendo.DataSource
API,并且网格将使用它作为它的 dataSource 对象。我不喜欢这个解决方案,因为我认为我会失去 Kendo 在Kendo.DataSource
对象中为我提供的许多功能。将
Kendo.DataSource
包装我们自己的EntitiesCollection
并将请求委托给它。包含的
Kendo.ObservableArray
对象Kendo.DataSource
将包装我们的EntitiesCollection
(参见我在网上找到的这个示例实现)。这种方法似乎适用于简单的用例,但是对我来说似乎有些问题-我认为这Backbone.Collection
不是data
对象(在剑道术语中)而是DataSource
对象-因为它是与远程服务器交互并获取数据的对象。