Greetings,
while working with the TWebDBResponsiveGrid I noticed that after unbinding and then bounding the DataSource to it ( at runtime ), the component goes through the creation cycle twice, effectively creating all the items once and then overwriting them on the second pass. I'm not sure if the items are effectively being drawn on the first pass since I only noticed this behaviour by logging the onItemCreated event. This is on version WebCore v2.9.2.1 , not sure if this has already been fixed in the latest update.
We could reproduce this. We traced & solved this issue. The next update will address this.
I'd like to take this opportunity to ask for a major improvement for the TWebDB ResponsiveGrid: partial fetching of data from datasets upon scrolling or paging features (always on connected dataset).
We decided to use TWebDBResponsiveGrid instead of any other TMS grid (which is always very slow in some ways). We therefore created a component that uses it to simulate a TWebDBgrid but is responsive, becoming cards at low resolutions (smartphones) or on demand, with the possibility of custom editing.
We would need partial data fetching because we often use grids on datasets that have 10,000-20,000 records already downloaded to the client (municipalities, cities, postal codes, and other tables), and therefore a TWebDBResponsiveGrid with partial fetching would be very fast and functional.
(Of course, we also use it for paging directly from the server, but that's another matter.)
Thanks
Isn't a more performant solution not to do paged fetching of data from the server?
You could do paged server data fetching to a dataset and the TWebDBResponsiveGrid will then automatically just show the page of data that was fetched in the TWebClientDataSet?
"(Of course, we also use it for paging directly from the server, but that's another matter.)"
This is what we already do. But for many datasets already on the client (downloaded at the start of the work session) and shared across different parts and forms of the application (municipalities, zip codes, cities, codes), and containing tens of thousands of records, it would be truly convenient and powerful to be able to manage these medium-sized datasets without slowing down the grid loading and scrolling. All on the client side, without constantly querying the server. Especially when summaries, totals, and averages need to be calculated on those datasets.
Sometimes we even download this data into a separate thread to make it available later.
The virtual pagination of the TwebDbresponsive grid on the dataset allows us to be very efficient and manage everything on the client side, having the entire table already in memory, greatly benefiting code development.
We will reflect on this.
Thanks Bruno,
basically, for our needs, we've found a way to reuse TwebDBresponsivegrid (by creating our own component) that allows us to use it both as a grid and as responsive cards (simultaneously). We're also adding the ability to make it editable, especially in card mode (in progress).
Since we can't rely on the FNC grid (too slow on some older devices) or TwebDBgrid (really slow even with 500 records), the best solution seems to be to adapt the native TMS web component, without using external components.
This is what we need to be able to port our VCL applications without losing flexibility and power.
But managing datasets with around tens of thousands of rows, downloaded directly to the client (obviously with just a few fields), would allow us to "move" the management of that data entirely to the client with little code and little effort.
The only problem we need to solve is how to prevent TwebDBresponsivegrid from creating HTML for all 10,000 records, because it becomes too slow to create and scroll. But by "buffering" the dataset and displaying a few hundred records per page (or fetching), it becomes our perfect companion (with 500, it's still efficient).
Downloading a dataset of 10,000 records and 10 fields takes a second or less. And being able to manage display, sorting, and filtering these datasets in our "custom" TwebDBresponsivegrid becomes incredibly convenient and, above all, fast, by leveraging the client's CPU, not the server's.
Alternatively, we would need a "virtual" dataset, connected to TwebDBresponsivegrid, which extracts the necessary rows from the original dataset, thus creating paging. But I don't think TwebClientDataset has these cloning capabilities :-)
Perhaps something can be done by filtering the dataset?
Our temporary solution is this: once TwebClientDataset A has been filled with the received JSON (Xdata custom service, 10K-20K records), a very quick operation, TwebDBResponsiveGrid is connected to a "shadow" dataset B, which is a "window" onto dataset A.
Basically, the records of the current page (100 records) are copied from dataset A (filtered and/or sorted) into dataset B, and then dataset B is connected to the grid. Even paging through 1,000 records at a time, the result remains acceptable on a decent PC.
I never thought of using the TwebDBResponsiveGrid as the main grid!
But the solution is sooooo homemade! :-)
Let's wait for some native, automatic, and modern solution.
Thank you