SlickGrid Vs JQGrid [fermé]

j'essaie de me décider entre slickgrid et jqgrid. Je pense que les deux sont riches en fonctionnalités. Jqgrid dispose d'une excellente documentation, il est donc facile de démarrer.

j'essaie de comprendre, à quel point ils sont différents, en termes de détails de mise en œuvre car j'ai entendu que slick grid est beaucoup plus rapide. Je me demandais juste si quelqu'un avait fait quelques benchmarking / connaître les internes de chaque grille pour fournir quelques entrées utiles.

Edit 1: @oleg-Merci pour votre réponse. Désolé, j'avais peur de ne pas avoir fourni assez de détails. Bien que je ne dispose pas de tous les cas d'utilisation, mais je vais utiliser à la fois les données locales lorsque les données sont petites et le défilement virtuel côté serveur, le filtrage, le tri, etc. lorsque les données sont grandes. Json sera la principale source de données. J'essayais d'obtenir des informations de quelqu'un qui pourrait comprendre les internes des deux grilles. Je ne comprends pas assez la mise en œuvre côté client pour juger ceux m'. Un de mes collègues a mentionné que slick grid pourrait être mieux puisqu'il a été développé avec le rendu virtuel et le soutien de clavier pour être avec. Ma question est ouverte, mais la mise en œuvre de base de la grille pourrait la rendre efficace dans les scénarios plus complexes, c'est-à-dire les sous-grilles, les arbres, etc. s'il n'y a pas d'écart par rapport à la conception de base pour traiter l'un de ceux-ci.

Ok, sur la base de l'expertise ur de jqgrid, comment répondriez-vous à cet extrait de De La Nappe De La Grille ?

grille vs données La principale différence est entre SlickGrid et d'autres implémentations de grid que j'ai vu, c'est qu'ils se concentrent trop sur la capacité à comprendre et à travailler avec des données (Recherche, tri, analyse, charge ajax, etc.) et pas assez sur le fait d'être mieux "grille" (ou, dans le cas d'modifiable grilles, une feuille de calcul). C'est génial si tout ce que vous voulez faire est de "préparer" une TABLE HTML ou de gifler un front end sur une liste simple, mais trop rigide pour autre chose. Les données sont compliquées. Il a des règles d'affaires. Il a des propriétés intrinsèques. Éditer une propriété d'un élément peut conduire à des changements en cascade modifiant d'autres propriétés ou même d'autres éléments. Il a des dépendances. Ce que je veux dire, c'est qu'il est préférable de laisser le traitement des données au développeur en utilisant le contrôle de la grille. Essayer d'intégrer tout cela dans l'implémentation de la grille et L'API ne fera que limiter son applicabilité et Ajouter un bloat considérable. SlickGrid prend un approche différente. Dans le scénario le plus simple, il accède aux données par l'intermédiaire d'une interface de tableau (c.-à-d. en utilisant "dataitem" pour obtenir un élément à une position donnée et "données.la longueur" pour déterminer le nombre d'éléments), mais l'API est structuré de telle manière qu'il est très facile de faire la grille de réagir à d'éventuelles modifications aux données sous-jacentes. "

Edit 2: Extrait de Datatables post sur le forum : "*DataTables , c'est . Cela peut être vu, par exemple, par l'utilisation de la balise TABLE par DataTables, tandis que SlickGrid utilise des éléments DIV pour créer un affichage qui ressemble à une table. En tant que tel, il existe un certain nombre de techniques, comme le rendu virtuel, qui peut être utilisé avec les DIVs - mais pas avec une table . Il n'est pas possible de simplement rendre les lignes 100-110 et pas les 100 premières dans une table, mais ce n'est pas un problème avec les DIVs, donc je crains que ce n'est pas applicable pour le moment. Ce qui devrait être fait est de convertir les datables à l'aide D'un marqueur de TAG DIV, mais alors vous perdez l'objectif principal des datables, qui est de mettre l'accent sur l'amélioration progressive et l'accessibilité.* "

Merci