In general, the Weblistbox seems nicely implemented. I do notice that performance on adding rows doesn’t seem as fast as it could be. I need to load up ~ 400 rows of 7 columns of info. I hope to get this way down with a decent search operation, However to be fair. I have a .NET application that loads a “smart grid” in about 1/2 the time it takes to loop through and load the 400 rows in XOJO. I’m loading all 7 columns with a single “add row” (which is a huge improvement over loading individual cells). My .NET smart grid extension offers sort by column / filter columns by / user resizable columns / and a “group by” option that generates a hierarchical view by grouping rows by column values. Lots of Bells and Whistles. You can place checkboxes, and drop down controls, icons, etc in the cells. All this plus 2X performance. Now I think the XOJO listbox is “ok”. And it’s no doubt one of the most powerful if not the most powerful WE control. I do have Taylor Designs webcustcontrols and the custom pseudo listbox seems very nice. I had some performance issues there too adding small icons to cells. It may have been my coding though. I’ll revisit his controls. I wonder where the XOJO bottleneck is though. Is it the “delivery” to the browser of the serialized data from the application? I wonder if like the single “add row” for 7 columns if the same thing could be done for rows so that I could “create an 2 dimensional array” and then “blam!” generate a Listbox in one fell swoop. Would that be any faster?
Did I mention that the .NET smart grid can be setup for cells/columns to be in-line editable? I use this feature and it’s intuitive for the end user.
Well, OK. If WebListBox meets your needs, great. If it doesn’t, there are some third party extensions to it. And there’s the WebSDK. You’re welcome to roll your own and share or charge as you see fit.
Internet latency is going to trump all other bottlenecks once you deploy a web application. There are some big advantages, like security, of Xojo’s Web Application architecture where all the app logic is on the server side. But there are performance trade-offs as well. It is what it is.
My initial reaction was too that the weblistbox is limited.
Once I spent a bit more time designing my app, I realized that for most of my purposes, it can be just about fine. The performance issue is real, but it is also inherent to working over the web. I decided to use the weblistbox as a window over data, meaning that I rarely load lots of data into the weblistbox, only what the user is requesting to see. The rest of the data is managed in a structure, a collection or whatever makes more sense for the specific purpose. It is somehat mode complicated to manage the data - cached locally and server-side, but in the end, I get a pretty responsive app.
There are some of my pages that require a more advanced, more flexible “data grid”, complete with in-line editing, database-driven dropdown lists in some cells, etc. I created my own using a container, labels, text boxes, popup menus, scrollbars, etc. In the end, I have exactly what I wanted. All it took was a bit of imagination and some time fine tuning all the events and the response to the events of my home made grid. It is definitely not for public consumption since it was specifically made for my own needs, but it is in the end better than what I would get from a stock grid. (in my totaly subjective and biased opinion, that is) For the record, I come from the VB world, and I am quite familiar with the various controls available on that side of the world (com and .net).
It’s worth keeping in mind that some candidates for a “Web Edition” app will be run exclusively on a high-speed LAN or WAN where the latency issues are far less severe than over the Internet.
Concatenating 400 rows (delimited by a line break) with 7 columns (tab-delimited) into a single string, and then stuffing that into a WebTextArea control is an order of magnitude or so faster than filling a WebListBox, even on a local network. I wonder if filling a WebListbox could be similarly sped up if there were a method to provide an array of rows to the control in one call.
Yes Peter, really that’s what I was wondering. My application runs on a local high speed network side by side with an “equivalent” .NET application. The “rows” come from a web service. The same web service is called from both the .NET and XOJO applications.
I know (via repeated trials) that the actual data comes to the application pretty darn quick. I can typically “refresh” the data in my .NET application two or three times (calling the data server each time and completely rebuilding the listbox) in the amount of time it takes to for the XOJO application to return once. If I update the XOJO application to build only one single row (regardless of how many rows come from the data server) the application comes back as fast
generally faster than the .NET app (which is building all 400 rows) . I’m pretty sure the bottle neck is how the listbox is being "built"
but also considered that it could be the serialization or whatever delivery process get’s it to the end users browser. If I could see the underlying code that builds the listbox
I’d probably have a better appreciation. It may be doing some sort of “append” operation that requires it to calculate the size of the current listbox object. As the number of rows increases
so does the time necessary to perform those kinds of calculations. Could be the difference between “for x = 1 to a 1000000” verus “for x = 1 to length(y)” where y is a string only 10,000 characters long. Pending on the language, the latter case scans 10,000 characters, 10,000 times
which is 100 times worse than simply counting to a million. There seems to be some strange performance issue with WebListbox. I may do some timed tests to try and estimate the O(x) complexity.