Slickgrid vs. jqGrid vs. ...？对于调度程序
我正在尝试评估创建资源计划查看器的工具。行是资源（带有可折叠的子行），列是时间（天、周等）。我研究过的网格框架似乎都无法在哲学上适应该用例（即松散定义的无限列），有人有任何建议吗？
I am trying to evaluate tools to create a resource schedule viewer. The rows would be resources (with collapsible subrows), and the columns would be time (days, weeks, etc). None of the grid frameworks I have looked into seem to accommodate that use case philosophically (i.e. loosely defined, infinite columns), does anyone have any recommendations?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用三个月后，我从 jqGrid 切换到 SlickGrid。
jqGrid 很好，毕竟它是最流行的 JavaScript 网格插件。但是：
文档不仅可能不完整，而且除了有些居高临下之外，还可能具有误导性。大多数情况下，您最终都会完成工作，但经过痛苦的调试/搜索例程之后。
以类似的方式，API 命名可能会好得多。例如：
addJSONData()实际上接受一个对象，或者某些方法的参数包括rowid和iRow。它尝试为您做所有事情，从 AJAX 调用到排序、解析数据和格式化数据。尝试按照自己的方式做一些事情，您会发现 jqGrid 不支持关注点分离。
这不是一个真正的开源项目 - 许多行实际上被混淆 - 而 SlickGrid 包括 JSDoc 注释和所有内容。
还没有尝试过 SlickGrid，但它看起来很不错。它的作者现在受雇于 Google，该项目在 GitHub 上有出色的统计数据。这些话让我彻底信服：
此外，虚拟渲染显然比仅仅删除 N 个
元素要优越。I'm switching from jqGrid to SlickGrid after three months of usage.
jqGrid is fine, after all it's the most popular JavaScript grid plugin. But:
Documentation can be not only be incomplete but also misleading, aside from somewhat condescending. Mostly you'll end up getting things done, but after a painful debug/search routine.
In a similar way, API naming could be much, much better. For example:
addJSONData()actually accepts an object, or a certain methods' parameters includerowidandiRow.It tries to do it everything for you, from AJAX calls to sorting, parsing data and formatting it. Try to do something your own way and you'll discover that jqGrid doesn't favour separation of concerns.
It's not a true open source project - many lines are practically obfuscated - whereas SlickGrid includes JSDoc comments and all.
Haven't tried SlickGrid yet, but it just looks so fine. Its author is now hired at Google and the project has excellent stats at GitHub. These words totally convinced me:
Also, virtual rendering is clearly superior than just dropping N
<tr>elements.