SlickGrid 与 JQGrid

发布于 2024-11-28 11:17:03 字数 1514 浏览 1 评论 0原文

我正在尝试在 slickgrid 和 jqgrid 之间做出决定。我认为它们都具有丰富的功能。 Jqgrid 有很棒的文档,因此很容易上手和使用。跑步。

我试图了解它们在实现细节方面有多么不同,因为我听说光滑的网格要快得多。我只是想知道是否有人做了一些基准测试/了解每个网格的内部结构以提供一些有用的输入。

编辑1: @oleg - 感谢您的回复。抱歉,我担心我可能没有提供足够的细节。虽然我没有所有的用例,但当数据较小时我将使用本地数据,当数据较大时我将使用服务器端虚拟滚动、过滤、排序等。 Json 将是主要数据源。我试图从可能了解两个网格内部结构的人那里获得输入。我对客户端实现的了解不足以让我自己判断这些。我的一位同事提到,光滑的网格可能会更好,因为它是通过虚拟渲染和键盘支持开发的。我的问题是开放式的,但网格的核心实现可能会使其在更复杂的场景(即子网格、树等)中变得高效,如果没有偏离核心设计来处理这些场景。

好的,根据您对 jqgrid 的专业知识,您会如何回应 Slick Grid 中的这段代码?

网格与数据 SlickGrid 和我见过的其他网格实现之间的主要区别在于,它们过于关注能够理解和处理数据(搜索、排序、解析、ajax 加载等),而没有足够关注成为更好的“网格” ”(或者,如果是可编辑网格,则为电子表格)。如果您想做的只是“修饰”一个 HTML TABLE 或将前端放到一个简单的列表上,但对于其他任何事情来说都太不灵活,那么这很好。 数据很复杂。它有业务规则。它具有非内在属性。编辑元素的一个属性可能会导致级联更改,从而修改其他属性甚至其他元素。它有依赖性。我的意思是,处理数据最好留给使用网格控件的开发人员。尝试将所有这些都融入到网格实现和 API 中只会限制其适用性并增加相当大的膨胀。 SlickGrid 采用了不同的方法。在最简单的场景中,它通过数组接口访问数据(即使用“dataitem”获取给定位置的项目,使用“data.length”确定项目的数量),但API的结构是这样的让网格对底层数据的任何可能的更改做出反应是非常容易的。

编辑 2: 来自 Datatables 论坛帖子 :“*DataTables 正在尝试美化 HTML 表格。例如,可以通过 DataTables 使用 TABLE 标记来看出这一点,而 SlickGrid 使用 DIV 元素来创建看起来像表格的显示。因此,有许多技术(例如虚拟渲染)可以与 DIV 一起使用,但不能与表格一起使用。不可能简单地渲染表中的第 100-110 行而不是前 100 行,但是 DIV 没有问题,所以我担心这目前不适用。需要做的是将 DataTables 转换为使用 DIV 标记标记,但是这样您就失去了 DataTables 的主要目标,即专注于渐进增强和可访问性。*”

谢谢

I am trying to decide between slickgrid and jqgrid. I think both of them are feature-rich. Jqgrid has great documentation, so its easy to get up & running.

I am trying to understand, how different they are, in terms of implementation details since I heard slick grid is lot faster. I was just wondering if anyone did some benchmarking / know the internals of each grid to provide some useful inputs.

Edit1: @oleg - Thanks for your response. Sorry, I was afraid that I might not have provided enough details. Although I do not have all the use-cases, but I will be using both the local data when data is small and server-side virtual scrolling, filtering, sorting etc. when data is large. Json will be the primary datasoure. I was trying to get inputs from someone who might understand the internals of both grids. I do not understand the client-side implementation enough to judge those myself. One of my colleague's mentioned that slick grid might be better since it was developed with virtual rendering and key-board support to being with. My question is open ended but the core-implementation of the grid might make it efficient in the more complex scenarios too i.e. sub-grids, trees etc. if there is no departure from the core design to handle any of those.

Ok, based on ur expertise of jqgrid, how would you respond to this snippet from Slick Grid ?

"Grid vs Data
The key difference is between SlickGrid and other grid implementation I have seen is that they focus too much on being able to understand and work with data (search, sort, parse, ajax load, etc.) and not enough on being a better “grid” (or, in case of editable grids, a spreadsheet). It’s great if all you want to do is “spruce up” an HTML TABLE or slap a front end onto a simple list, but too inflexible for anything else.
Data is complicated. It has business rules. It has non-intrinsic properties. Editing one property of an element can lead to cascading changes modifying other properties or even other elements. It has dependencies. What I’m saying, is that dealing with data is best left to the developer using the grid control. Trying to fit all of that into the grid implementation and API will only limit its applicability and add considerable bloat.
SlickGrid takes a different approach. In the simplest scenario, it accesses data through an array interface (i.e. using “dataitem” to get to an item at a given position and “data.length” to determine the number of items), but the API is structured in such a way that it is very easy to make the grid react to any possible changes to the underlying data.
"

Edit 2: Snippet from Datatables forum post : "*DataTables is trying to spruce up an HTML table. This can be seen, for example, by the use of the TABLE tag by DataTables, while SlickGrid uses DIV elements to create a display which looks like a table. As such, there are a number of techniques, like the virtual rendering, which can be used with the DIVs - but not with a table. It's not possible to simply render rows 100-110 and not the first 100 in a table, but it's no problem with DIVs, so I'm afraid that this isn't applicable at the moment. What would need to be done is to convert DataTables to using a DIV tag markup, but then you loose the primary goal of DataTables, which is focus on progressive enhancement and accessibility.*"

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

羁绊已千年 2024-12-05 11:17:03

我查看了jqGrid和SlickGrid,发现SlickGrid写得优雅得多; SlickGrid 的大多数用例都需要较少的配置;然而,jqGrid 需要较少的配置来设置更复杂的情况(例如虚拟滚动);

jqGrid 可能有更好的文档,但是 jqGrid 的服务器端连接部分包含在商业产品中,并且这部分的文档比客户端更难获取。

另一方面,SlickGrid 有一些很棒的示例,涵盖了大多数用例,并且源代码充满了注释,任何具有 javascript 和 jquery 中级知识的人都可以访问。

I looked at jqGrid and SlickGrid and found that SlickGrid is much more elegantly written; less configuration is needed for most use-cases for SlickGrid; jqGrid, however, need less configuration to set up the more complex cases (such as virtual scrolling);

jqGrid might have better documentation but the server-side connection part for jqGrid is covered by a commercial offering and documentation on this part is more difficult to obtain than for the client-side.

SlickGrid, on the other hand, have some great examples which covers most use-cases and the source is full of comments and is accessible to anyone with some intermediate knowledge of javascript and jquery.

水染的天色ゝ 2024-12-05 11:17:03

使用过 jqGrid 和 jqGrid ;生产/愤怒中的 slickgrid,这是我的 2 美分:
jqGrid 非常容易上手和使用。但是我们很快发现自己对必须将我们想要的内容融入 jqGrid 的做事方式感到恼火。我们还发现编辑功能很难实现,并且(根据记忆 - 这是一年前的事)它迫使您进入行编辑模型,而不是性能不佳的单元格编辑。

使用光滑的网格,我们还没有找到缺少的功能/我们无法轻松插入。该文档几乎不存在,但现在好多了(https://github.com/mleibman/SlickGrid/wiki/_pages ),但迄今为止我们只是跳入源代码。不得不说,该 API 是我见过的最好的 API 之一,并且大数据量和复杂编辑器的性能非常出色(ie7 上存在一些问题,但与我们的 MVC 框架和复杂编辑器相比,从未将其隔离到网格

中 )所有,我强烈推荐光滑网格

Having used both jqGrid & slickgrid in production/anger, here are my 2 cents:
jqGrid was very easy to get started with and hook in. However we quickly found ourselves grating against having to fit what we wanted into jqGrids way of doing things. We also found the editing capabilities difficult to implement and (from memory - this was a year ago) it forced you into a row edit model, rather than cell edit which did not perform well.

With slick grid we have yet to hit a feature that was missing / we could not easily plugin. The documentation was fairly non-existent but is now much better (https://github.com/mleibman/SlickGrid/wiki/_pages) but to date we've just been jumping into the source. Have to say the api is one of the best I've seen, and performance with large data volumes and complex editors has been excellent (some issues on ie7 but never isolated that to the grid vs our MVC framework & complex editors)

All in all, I'd highly recommend slick grid

独﹏钓一江月 2024-12-05 11:17:03

哪种语言更难学:汉语、芬兰语还是印第安纳州一些小民族的语言?

比较问题总是太难。您必须拥有真正了解您想要比较的所有产品的人员。此外,您应该定义您现在计划使用产品的哪些部分以及哪些部分在将来可能很重要。您使用 JSON 或 XML 数据作为网格输入,还是使用本地 JavaScript 数据?您是否需要使用标准网格或带有子网格的网格、树形网格或带有分组的网格?

在您没有更清楚地定义网格的使用区域之前,您将不会收到任何好的答案。最后,有时您当前拥有哪些专业知识以及您可以轻松理解和使用哪些文档或示例甚至可能很重要。您可以使用的其他人的经验可能比产品的功能更重要。如果您查看 stackoverflow.com 上带有标签 "jqgrid" 和带有标签 "slickgrid" 您可以查看哪些产品可以帮助您 stackoverflow

Which language is more difficult to study: Chinese, Finnish or the language of some small Indiana folk?

The comparing questions are always too difficult. You have to have people who really good knows all the products which you want to compare. Moreover you should define which part of the product you plan to use just now and which could be important in the future. Do you use JSON or XML data for the grid input or you use local JavaScript data? Do you need to use standard grid or grid with subgrids, treegrid or a grid with grouping?

Before you not define the area of the usage of the grid more clear you will not receive any good answer. At the end is sometime could be even important which know-how you have currently and just which documentation or examples you can easy understand and use yourself. The experience of other people which you can use could be more important as the features of the product. If you look at the number of questions on the stackoverflow.com with the tags "jqgrid" and with the tag "slickgrid" you can see in what product could help you stackoverflow

网名女生简单气质 2024-12-05 11:17:03

我同意@user175528。我们也在我们的应用程序中广泛使用了网格,它内置的格式化程序、编辑器和验证器非常易于使用,并且也很容易编写自定义的。

它可以很好地处理大型数据集(并且使搜索变得轻而易举)。此外,它还可以轻松设置分页和排序。

最初,当我开始使用 slickgrid 时,我将其包装在另一个小部件中,以便我可以在需要时转移到另一个提供商,但截至目前,它似乎工作完美。

我还没有抽出时间,但我将在我的博客上提供一些很好的 slickgrid 示例。

I agree with @user175528. We've used the grid extensively in our application too and its built in formatters, editors and validators are really easy to use and its easy to write custom ones as well.

It handles large datasets well (and makes searching through them a breeze). Additionally, its easy to setup paging and sorting.

Initially when I started using the slickgrid, I had wrapped it in another widget so that I could move to another provider if need be, but as of now, it seems to work flawlessly.

I haven't gotten around to it yet, but I will be posing some good slickgrid examples on my blog.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文