Does Handsontable support server side pagination like jqgrid? - jqgrid

Does Handsontable support server side pagination like jqgrid? handsontable

If you are looking for a pagination where you define some methods in the table definition and that magically handles the pagination I think the answer is NO, HT focus more on the presentation of the data to be more like Excel sheets leaving the pagination to each implementation. At the beginning I was not very happy about that, but you can handle the pagination by yourself using any strategy you decide and later updating the content of your table using "loadData".
Now, if you are looking for a scroll pagination approach, that is something I have not explored enough, HT has a very smart scroll strategy where only creates the elements that needs making the render very fast when working with large sets of data, so, I am not sure that type of scroll you are expecting it is possible as HT needs to know the total data size to correctly draw the vertical scrolls, maybe if you create empty rows for all data your expecting giving a static height each and later when you detect new data is needed while scrolling you fetch from the server side the missing data you can achieve the same result, here seems that feature was discussed Infinite scroll

After some research, found it doesn't support server side pagination.

Related

Use hierarchical tables in SlickGrid

We have a request from our designers to build tables something like this, with rows that expand to show essentially another sub-table underneath. In KendoUI documentation, this is called "Hierarchy."
We use SlickGrid v2.3 with a few additional plugins. We currently have tables with a similar row expand/collapse like this: https://mleibman.github.io/SlickGrid/examples/example5-collapsing.html . That does not allow for a completely different set of columns in the sub-table.
The question is, can this be done in SlickGrid or not?
It might be hard to do with current SlickGrid, there's no code that handles the hierarchical part itself so that would be lot of work to implement in SlickGrid. However it is implemented in Slickgrid-Universal, which is a wrapper on top of SlickGrid. You can see Example 5 and Example 6 which shows 2 types of Tree Data grids (hierarchical or parentId refs). We use it in production for a project that we have. Also note that this is not a grid within a grid, it's rather an expand/collapse the same as what you found in example5-collapsing.html, the only differences with SlickGrid is that Slickgrid-Universal has the code to deal with hierarchical data (filtering/sorting) while SlickGrid itself doesn't and also another nice to know thing is that expand/collapse is actually using data filtering behind the scene and you can see that in the total items displayed when you have the footer enabled.
Please note that I'm the author of Slickgrid-Universal and also a major contributor to SlickGrid as well
At the moment, it can't be done. In order to achieve its speed, Slickgrid enforces a fixed row height and a single scrolling canvas. It's just a different approach than used by HTML display grids.
You could put together a workaround using mutiple slickgrids or an embedded slickgrid in a group row, I suppose, but it would be messy.
One thing I have done is develop a SlickCombo, which is essentially a grid presented as a multi-column dropdown. It's a full grid and can offer editing.
That's probably as close as you'd get.
A comment: the MLeibman repo is long dead - you should be using: https://github.com/6pac/SlickGrid

Ag-grid row models: pagination vs virtual paging vs viewport

As title says, I would like to know how to decide which row model to choose and the reason why, depending on how the data change and the number of rows, for example.
Viewport - Use when you need to show realtime data, the server will maintain an open connection to update the grid whenever new data is ready.
Pagination/Virtual Paging - these are both about the same, just depends on what you want for your UI. In both situations you would use them if you have a lot of rows to show, but don't want the user to wait 10 min for the server to respond. Probably works best if you sort/filter on the server side.
Other notes:
In my opinion, if you have pagination, then don't have any scroll. I hate scrolling a table to realize that what I am looking for isn't on that page, then scrolling through another page. The only exception for this is if you have some sorting to your paging, like if the first page was all the A's, or had only from 2000, or just January's data.
Also, Pagination can be used in situations where you don't have a lot of data to request from the server, it could just be a UI preference.

BIRT- converting table to grid

Currently I'm working over a birt report with a table to display data. Now, i want to convert the same thing to grid, which provides better viewing and analysing capability. So, is there any easy way (in editing the XML or something) to convert the whole table to grid? Meanwhile, the complete data remains the same.
NB: I havn't yet used a bit with grid, never ever! Also m bit newbie to birt. So pardon me if I'm spiting out anything rubbish.
A table is a different element from a grid. There is not a button to push that will convert one to the other. You would need to add a grid element to your report and set it up like you want it to look.
I seriously doubt you want to do this though. a grid will only display the first record returned, unlike a table that will display all the records returned.
A related, but more reasonable question is how to convert a single-column table to a list or vice-versa.
I often need this table-to-list conversion for optimizing master-detail reports for (our customized version of) the WordEmitter, because this prevents superfluous nested tables in the Word output.
Fortunately, for tables without grouping this is relatively easy by editing the XML:
Change the corresponding opening and closing tag to a tag, remove the elements and the elements (but keep theirs contents).
Apart from that, James' is right: There is no reason to convert a table to a grid item, mainly because a table will display all records (while a grid displays only the first) while the table has all features of a grid (and more, like grouping).

Why do jqgrid, flexigrid and ingrid all use separate tables for the header and data?

We're using jqgrid on a web application to render the results of searches because of its built in functionality for paging and sorting that executes server side. We were previously using Tablesorter, but that operated client side and so didn't work well for how we were trying to use it.
We had a web designer on the project (whom has since left the organisation) that had created styles for tables and tried to get the same look working on the jqgrid. It sort of worked, but not quite. We have trouble with the header columns being unaligned with the data columns. We've fiddled with the CSS but it just doesn't seem to work. Sometimes we get scroll bars appearing when we don't want them.
Anyway, part of the problem seems to be that jqgrid uses one table for the column headers, and then another for the data itself. These tables are each wrapped in a div tag. We've had a look at some of the alternatives such as Flexigrid and Ingrid but they also use the same approach with separate tables for the headers and data.
It would be great if someone could explain why this approach is used. We were wondering why a standard table tag with a row of th for the headers and td for the data couldn't be used instead?
The reason these plugins use separate tables for headers and data is to allow for fixed header scrolling. As far as I know you cannot have headers and data in the same table, yet fix the headers to the top during scrolling.
Also for your alignment issue, if possible, I believe these plugins all have settings where you can set how wide you want each column, and this will make the data and header columns line up properly.

Is it possible to dynamically change the page size in a YUI Paginated Datatable?

I have a YUI Datatable which is paginated. The height the datatable is able to use can change. What I want to happen is that when there is a size change (which I already have a handle on), I can take the new height and find how many rows are going to fit in a page, then change the datatable or it's paginator to have that number of rows.
Is this something that is possible with YUI Datables, if so is there examples or documentation about it?
myDataTable.get('paginator').setRowsPerPage(25);
It appears that if you can get a reference to the YAHOO.widget.Paginator instance, you can call:
theTablesPaginator.setRowsPerPage(numRows, silent)
Where the silent option allows setting whether the changeRequest event should be sent. If you wish the datatable to redrawn, set this to false.
Reference: the very useful official YUI documentation

Resources