KlausSchaefers
Feature: Pagination on Grid widget
It could be good if pagination can be implemented on the grid, as now it has a scroll but you don't always want a scroll. I tried to do pagination with grid, and with <> and with a good built data structure you could do it, but I was stuck on a limitation: any content inside a grid has an implicit parent of the grid's data-binding, so it seems I cannot escape from that parent to do a lookup to another data structure level (in my structure I have all items in one place, pages in another place and current_page (or index) in a third place). I will do it with plain components, since the grid I want is fixed in number of rows&columns, but anyways it would have been great if the grid already did that with a simple fixed row/column count + two data bindings, one for the items, and one for the starting-index.
any content inside a grid has an implicit parent of the grid's data-binding, so it seems I cannot escape from that parent to do a lookup to another data structure level (in my structure I have all items in one place, pages in another place and current_page (or index) in a third place).
Yes this is a current limitation. So your idea is the following. Suppose you have data like this
{
items:[],
variabelA: true
}
The grid would be bound to items, but you would want to bind some grid children to variableA?
No, the grid is not buggy, is acts intuitively. The pagination would be a feature, alternative to the scroll, with using two data-bindings, and doing the logic I already did with JS, in the core functionality of the grid's component (native support). But if you would want to just give the possibility to use the grid but with alternate structures, then you would just need to modify your parser to also allow "external" bindings (not children of the data-binding of the grid itself) - the data binding parser is limited in here, I saw that with other ocasions as well. Anyways, this approach is half-way what I proposed, and I already implemented pagination with simple components, so it is doable with the new <> widget and simple group/custom components, no problem. You can do it only if you want, it was a proposal from me, it would have been nice to have that natively.