为什么我不应该使用 jqQgrid 的任何技术问题 [关闭]答案

【问题标题】：Any Technical Issue why I shouldn't use jqQgrid [closed]为什么我不应该使用 jqQgrid 的任何技术问题 [关闭]
【发布时间】：2011-11-23 05:40:03
【问题描述】：

我们即将替换使用 ExtJS 网格并计划使用 jqGrid 的大型代码库。只是想知道是否有已知问题会阻止我们这样做。

我不是在寻找好的或有更好的选择。我正在寻找使用过它的人，他们要么有良好的体验，要么在用例或规模或类似方面遇到过一些可能让我重新考虑的技术问题。

【问题讨论】：

我无法评论 jqGrid，因为我没有使用它。但是，如果您希望“缩小”以实现更小/更快/更高效的实现，我最近真的很喜欢基于 jQuery UI 的 wijmo。不，wijmo 网格无法制作吐司，但它确实可以制作网格！

【解决方案1】：

我发现它总体上是一个优秀的图书馆。每隔一段时间我就会遇到一个小错误，我可以自己修复，或者我可以从 Github 反向移植修复，或者等到下一个版本可能会修复它。如果它在功能和用例方面满足您的要求，我会说肯定会去。从技术上讲，我认为该插件是一流的。

【讨论】：

【解决方案2】：

如果它对您有帮助，它正被多家大型网络公司用于管理目的。我记得在几次采访中与 jqGrid 打交道。

【讨论】：

是的，但是 ExtJS 也是如此。被其他人使用并没有像许多开发人员的综合意见那样对我说太多。总会有某人会使用任何组件。如果您对 jqGrid 有一些经验，那么听取反馈会更有价值。

【解决方案3】：

我在一个要求相当复杂的大型项目中使用 jqGrid 3.7（例如，在隐藏选项卡上初始化网格，使用 json 数据按需更新网格，自定义排序/选择操作，将网格数据重新序列化为 json，分页，可配置的网格高度）。

一开始，一切看起来都很好，但是当我们添加更多功能时，jqGrid 暴露了很多缺陷。 jqGrid API 相当臃肿，代码库中根本没有测试。这让我们最终放弃了 jqGrid 以换取另一个网格解决方案（它更好地满足了我们的要求，但也不能满足我们）。

jqGrid 有一个活跃的开发社区和频繁的发布，因此您可能可以破解它的故障。但是对于一个非常复杂的网格，我会选择基于 MVC 的解决方案 - 这允许您将网格数据保存在一个单独的模型中，该模型可以被其他 UI 组件（例如图表小部件）重用

更新：放弃 jqGrid 的原因

我们为 SlickGrid 删除了 jqGrid，StackExchange 也使用了它/is(?)。

放弃 jQGrid 的主要原因是无法在隐藏的 jQuery UI 选项卡上初始化网格、样式设置困难以及希望为我们所有的小部件使用通用数据模型而不是为每个数据编写数十个不同的模型我们使用的可视化小部件（图表、网格、树视图等）。

SlickGrid 通过其虚拟渲染技术为我们带来了性能改进，但也有其自身的故障（例如，分页网格中的选择无法正常工作）。现在我们正在测试grid component in KendoUI，也许我们也会考虑新的grid widget of jQuery UI。

【讨论】：

【解决方案4】：

完全披露：我为Kendo UI工作

Kendo UI 网格设计为轻量级和极快的。它目前具有广泛而强大的功能集，包括多个排序、分组和自定义工具栏。

此外，Kendo UI 有一个DataSource，它可以在使用网格解决方案进行编辑时真正简化处理 CRUD 操作的过程。

更不用说您获得了 Kendo UI 附带的所有其他小部件。您还可以获取数据可视化组件，并在新年后查看原生移动套件的预览。

【讨论】：