Are there any WEB components like TListView that let you click on the header to sort based on a column?
TWebStringGrid, TWebDBGrid
I'm using TWebStringGrid now ... it's not clear how to sort columns. Is there a demo of that somewhere? Or can you give me a rough outline of what's needed?
DBGrid demo has sorting. Click on column header cells.
I'm not using a DB, I'm pulling data from a REST API.
Well, I replaced the TWebStringGrid with a TWebClientDataSet and a DBGrid.
The StringGrid only takes a few seconds to load.
The same data takes 45 seconds to load into the table and appear on the DBGrid.
That's a crazy amount of overhead just to be able to sort columns.
And I don't even have the column sorting implemented yet.
It is hard to judge without seeing details.
How much data is this? Is this timing related to loading in the dataset or due to connecting the dataset to the TWebDBGrid?
If you have an endpoint from where we can get this data, we can investigate.
The data consistently comes down in about 10 seconds. I'm loading each record into an object and putting that onto a TList. There are about 150 records. There are 8 or 9 strings in each record, between 5 and 20 characters. Nothing big. A dozen or so have a longer string (100 chars or so) in the last field, otherwise it's empty.
Then it takes another 10 seconds to show up in the StringGrid.
However, it takes most of 45 seconds if I'm using the DataSet. It just goes through the list and does an Append ... Post for each record. I also use grid.BeginUpdate... EndUpdate around the loop that's adding the records.
I'm guessing that the dataset just runs really slowly inside of the browser.
I suspect that if it's possible to detect a click on a column header, I can refresh the StringGrid after sorting the data on that column.
Unfortunately, grids aren't ideal for use with mobile devices like cell phones, so I'm not sure if it'll make it into the final design. I may be better off with some smaller vertical panels (Cards?) that are twice as high as wide, and you can scroll them horizontally. But for now, the grid works. However, using the DB is WAY too slow to load.
We've investigated this deeper and we have now significantly accelerated this.
This improvement will be in v2.1
To add sorting in TWebStringGrid, all you need to do is add for the columns where you want to allow the user to sort, to call grid.AddSortIndicator(column, 0, siNone);
Then click on the sort triangle in the column header to sort on columns.
1 Like
I noticed the various properties for sorting, and I was going to try them out shortly.
But I've added a few small card panels to scroll left and right rather than use a grid. It's not like a "slider" that makes it look like there's something actually moving left and right, as the card panels stay put. But the data moves through them left and right.
I'm having a challenge with the images on these cards. I grabbed about 150 generated headshots from a site that I can use, but the only way to load them up is if they live somewhere else. The data I'm getting doesn't have images, so I'm puzzled where to store them. Maybe on Dropbox? They're really just random, but I think it will help to have them there in this situation. Eventually I'll be adding data from "real people" and then they'll be more relevant.
This web app thing is like learning OOP again ... things that you're used to doing some way don't work that way any more! So I apologize if some of the things I say don't make sense.
I'm not sure what the exact problem is with the images. If you have the URL to these images, it should be straightforward to include these into any control or HTML element in your app.
If your problem persists, please elaborate.
The problem is they can't be stored locally, they need to be stored somewhere that's accessible on the web. Do you think FB works by saving all images on your local device? No, they're loaded up dynamically. There are millions of images added to social media daily.
In my case, I'm only working with 150 of these images at the moment, as I'm just doing some basic testing; that number could grow to thousands. But while a desktop app might store them "locally" and update the collection regularly, a web app can't really do that -- in part because the web browser has no notion of "local storage". Yes, after a fashion, there are places things can be saved, but if you use multiple browsers, all of that data ends up being duplicated. Instead of multiple user logins on a desktop that are split between common and user-specific storage, mobile devices present you with one user, but multple browsers, and all of their data spaces are kept separate on a per-browser basis, in the same way that Windows keeps local "private" storage for user accounts separate. (The ApplicationData folder in Windows actually has a few different types of storage, depending on your specific needs.)
Browsers have replaced "users" in terms of organizing data. Now, "users" have become a more ephemiral entity that are more like shape-shifters that change based on what 3rd-party services they're interacting with. FB, IG, Twitter, Tiktok, ... all of these "users" have different profiles, and they're all different aspects of the same person. The browser becomes the common repository for all of that "shared" data. But don't try switching browsers because they can's share any of that data. Or maybe that's the point?
I saw a post someone made recently saying that the latest version of Android no longer allows sharing data between two different apps (well, task threads launched by the same app) running in parallel on the same device; each one runs in its own security silo to prevent it from causing problems with others.
It's a very different way of thinking about app development and needs. There might be a notion of "local storage" but it's browser-specific. And there are issues with async requests that don't exist in desktops either, unless you explicitly set them up. With web apps, they're everywhere.
I can load up an image in a control in the IDE becuase the IDE can reach into my local HDD. But my web app cannot do the same thing if I want to put all of those images in a local folder and load them as-needed. I don't preload them into my app; I guess if there was a TWebImageList then I could, but it needs to be updated periodically; how can I do that if it's set up at compile time? Otherwise, each browser needs its own copy of all that common data. Storage on the hardware platform can no longer act as a shared resource the way we've gotten used to Windows doing it.
We're basically being forced to switch back to a "file server" mentality to access shared resources. But what services offer that kind of support?
Maybe what's needed is something in myCloudData that offers an API that looks like an external file store to web apps that can store files of different types, like images, INI files, and whatnot, that our web apps can use to manage shared content. That is, data that's private to our app, but used by all instances running everywhere. The alternative is having to constantly download and manage that data "locally", which just adds more complexity to the problem. (And yes, I know that myCloudData is built on top of a general purpose DBMS, but dumping things into a DBMS to be used the same way a disk folder works takes a lot more effort than simply copying them into a folder. You can't just use a BLOB that ends up being downloaded to the device each time you need something so you can extract a tiny bit of data from it here and there.)
Maybe I should be looking at Amazon's S3 or Google's storage solutions instead?
Or maybe Dropbox? Do you guys even support Amazon's services?
If you get a shared image URL from Dropbox or Amazon or Google, you could use that URL from a TMS WEB Core app.
If they are not private you could use IPFS.
I feel compelled to add a few thoughts to this discussion, particularly the higher-level web vs. desktop scenarios presented here. There most certainly is a different approach needed in how these kinds of things are handled in a browser environment vs. a desktop environment. How user data is handled, in particular, is dramatically different, but not without very good reasons.
Keeping user data from one application private from other applications is far more important when these other applications are actively trying to use your private data against you. Facebook, for example, should be considered an adversarial app - no different than a virus running rampant on a Windows system. I'm not being flippant or overly dramatic here - these other apps really are up to nefarious things, so much so that these kinds of browser restrictions have been implemented to combat them head-on.
Browser local storage is a mechanism that also works very well for its intended purpose - storing state information about an application. But images are a special case in browsers. You might store references to images (the URL links) in local storage, but the browser itself caches images pretty well all on its own if you use such links. No need for any kind of local storage work is required on the part of the developer. This offloads a huge amount of work and responsibility - so long as the browser can access the images.
And it can be super-efficient as well. Check out the Actorious project - scroll the tables a little bit - the browser automatically caches images and does "lazy loading" to only load images when they're actually needed. There is no image data stored in the "local storage" part that the developer manages - it is all managed by the browser itself.
And yes, switching browsers incurs a penalty in that the browser's cache or the local storage state is not carried over. But if you do have user-specific state, then yes, certainly, some kind of remote cloud storage mechanism (backed by a database or otherwise) is required, just as would be the case in any client/server desktop app. But this penalty is far less than switching from one Windows desktop, where your app is installed, to another where it is not installed. We're much farther ahead already in the browser environment.
If you just have a general set of images that need to be available to your application, they can be put in a folder in the same place that your application is being hosted, and referenced from there - no third-party services required - as an alternative to referencing a local folder containing relatively static images, for example.
Nothing is really lost in moving from a desktop environment to a web environment. Rather, there are considerable gains, particularly for image-heavy applications. Just takes a little time to get acclimated.
You guys are overcomplicating what's needed here.
I think I'll just throw the files into a folder on one of my hosting accounts and just access them that way. It's really all I need in this case.
1 Like