I've a situation where I've multiple columnGroups inside my datatable and for each record I render one or more columnGroup depending on some business logic.
Now, since the number of rows in the datatable are different from size of my records list, how do I get total number of pages in the datatable, provided that the number of rows per page is some fixed number let's say 60.
I need that number for my custom datascroller.
Related
I haved this Tabulator table with grouped rows.
Pagination is activated.
Say page size is 5.
If I have a group of 3 rows and a group of 2 rows, then I see:
the header for group 1
the 3 rows of group 1
the header for group 2
I have to go on the next page to see the 2 rows of group 2 (with no header)
How can I make sure row groups are not cut this way?
I'd like to find a way to tell Tabulator: "if a group cannot fit into a page, then start it on next page"
Of course I guess that would be a problem if a group would be larger than the page size, but then an error would be fine (or I guess I could check that before setting the page size)
This is not possible with Tabulator. When using pagination in Tabulator you define a page size in a number of rows.
This counts as the number of visible row elements, which includes normal rows, group headers and calculation rows.
The reason for this is to create a smoother user experience by ensuring that each page has the same number of visible rows and maintains the same height.
If the table changes height every page because it contains a different number of elements, it would cause the pagination buttons to move about which would be jarring for the user.
I would like to use Tabulator's remote pagination to load records from my database table, one page at a time. I expect that I should be able to use the page and size parameters sent by Tabulator to my remote back-end to determine which records to select from the database.
For example, with page=2 and size=10, I can use MySQL's LIMIT 10,20 to select the records to be shown on page 2 (if size is set to 10).
However, doing this precludes me from using the count of all records to determine the number of pages in the table. Doing a count on the returned records will only yield 10 records, even if there are a total of 500 records (for example), so only one pagination button will be shown (instead of the expected 50 buttons).
So in order to do remote pagination "correctly" in Tabulator, it seems I must do a query to count all records from my database (with no limits), then do a count to determine the last_page, and then do something like PHP's array_slice to extract the nth page's worth of records to return as the dataset. Or I can do 2 database queries: count all records to determine # of pages, and then do a LIMIT [start],[end] query.
Is this correct?
Tabulator needs to know the last page number in order to layout the pagination buttons in the table footer so that users can select the page they want to view from the list of pages.
You simply need to do a query to count the total number of records and divide it by the number of page size which is passed in the request. you can run a count query quite efficiently returning only the count and no data.
You can then run a standard query with a limit set on the records to retreive the records for that page.
If you want to optimize things further you could stick the count value in cache so that you dont need to generate it on each request.
I have multiple views with categorization. Sometimes the view displays as it should in native Notes but other times the categorized column text wraps under the twistie and other times the column is wide as if it weren't categorized taking too much room up on the page. I'm using simple views. Can someone shed some light, I've compared and looked all over to find what to do.
Categorized columns "overlap" if you don't show "total" columns.
As soon as you show a total column in xp:viewPanel - categories are put in separate table columns and don't overlap anymore.
I am having a list of 20 rows, and i have used tr:table to list it with 10 rows per page.
{}
In this, the first 10 rows are getting displayed, but the next rows cannot be viewed.
Is there any solution for this.
I have a wide column family used as a 'timeline' index, where column names are timestamps. In order to prevent hotspots, I shard the CF by month so that each month has its own row in the CF.
I query the CF for a slice range between two dates and limit the number of columns returned based on the page's records per page, say to 10.
The problem is that if my date range spans several months, I get 10 columns returned from each row, even if there is 10 matching columns in the first row - thus satisfying my paging requirement.
I can see the logic in this, but it strikes me as a real inefficiency if I have to retrieve redundant records from potentially multiple nodes when I only need the first 10 matching columns regardless of how many rows they span.
So my question is, am I better off to do a single Get operation on the first row and then do another Get operation on the second row if my first call doesnt return 10 records and continue until I have the required no. of records (or hit the row limit), or just accept the redundancy and dump the unneeded records?
I would sample your queries and record how many rows you needed to fetch for each one in order to get your 10 results and build a histogram of those numbers. Then, based on the histogram, figure out how many rows you would need to fetch at once in order to complete, say, 90% of your lookups with only a single query to Cassandra. That's a good start, at least.
If you almost always need to fetch more than one row, consider splitting your timeline by larger chunks than a month. Or, if you want to take a more flexible approach, use different bucket sizes based on the traffic for each individual timeline: http://www.datastax.com/dev/blog/advanced-time-series-with-cassandra (see the "Variable Time Bucket Sizes" section).