My small app is done and works great. Now I am looking into the next project. This one will be bigger. And there lies my issue. I will be having multiple forms accessing a database, performing calculations, generating reports on screen and to be printed out and it will be used for 100 or 200 users at a time.
My first reaction was: PHP. But I had such a great time with WE that I want to think it through first.
So my head is now filled with questions such as:
Any way to dynamically load forms?
How to optimize memory management?
I think that some reports could be done on a separate process or something and then show them on a HTML window
How to better address performance?
what do you think about segmenting the app into multiple smaller apps and then executing them as needed?
a. How can this be implemented?
b. is it worth it?
c. How will the CGI behave under this circumstances?
Your thoughts, ideas and strategies are welcome.
Also valid: forget about it and do it using another tool.
I would also appreciate a “best practices for large-ish web apps” thread. In the past, I’ve done this kind of thing with PHP & etc., but Xojo is so close to being usable that I’m considering it for a substantial app. Like Andres’ app, this will be used by dozens to hundreds, not tens of thousands (which is why I can consider Xojo in the first place).
And please don’t say “wait for XDC” – I can’t hold off on this until March.
You can load page content dynamically using WebContainers.
For stuff that can be shared across sessions (images come to mind), storing them once globally is better than loading them up for each session.
Sure, you could definitely have “helper” console apps running on the web server that do stuff in the background that the main web app can then use. This also has the benefit of spreading out the memory and CPU load.
I’ve just started something similar that I will probably park on Amazons AWS, and although coding is at a very early stage, I’ve prototyped a few console apps that will run as needed to dump or process data in a database and then the WE will simply serve what is needed when it is needed. Well, that’s the theory for now anyway!
I think my biggest barrier to doing a business-oriented (as opposed to social media) web app in Xojo is the primitive nature of the web listbox. Some of the jQuery-based grid controls are quite amazing these days, and I’d have to do a whole lot of custom development to get something like them working in Xojo.
That is certainly a big issue. For me though, the speed at which we developed our first solution was simply… amazing. I think I could devote some time to create reusable customized web list boxes.
I think a substantial number (some integer less than a thousand) of people on this forum would appreciate a highly-performant, feature-rich web grid control. Not merely a “listbox” (I view those as heavily slanted towards viewing only, rather than data entry), but a grid that allowed data viewing with formats, as well as data entry with a number of different controls (drop downs, date pickers, etc.), intelligently handled text wrapping, column resizing, and a slew of other features. Intelligent paging would be a plus.
If somebody had the time and skill set to develop such a thing (I probably have one but not the other, not sure which one though), I would gladly pay a license fee as I have to several other plug-in developers. That person certainly couldn’t make a living off the fees received from the Xojo community, but such a grid control surely would be welcomed. I think.
You can do this already without using the listbox. We do this all the time using 2 WebContainers. The first is the ‘row’ of controls which can be any control or a web container. Then you create a ‘list’ container and rows to it.
I think this is one of the biggest strengths of Web Edition that is largely overlooked by many. You can make some very powerful ‘grid’ controls. We’ve done a complete Accounting application using this approach.
For a web app you will definitely want to do paging of your data. You do not want to load one of these repeating row list boxes with 1,000’s of rows. We usually limit it to 50 rows at a time but that’s purely arbitrary. Most people using web apps understand paging of data so it’s not a big deal for users.
Mr. Keeney: that statement alone made my day. Do you happen to have screenshots, or any insights that you could share with us in terms of what problems oyu faced or what pitfalls to avoid?
I can’t share any screenshots because of NDA. Web Edition controls don’t like the Open event (used Shown instead). There are currently some bugs in web containers that if you load them while they are invisible controls won’t work very well.
We use tons of dynamic web containers. This can be slow at runtime depending upon their complexity. Sometimes it’s faster to just put the container on the webpage at design time if you can get away with it.
This project has about 250 tables (all done with ActiveRecord), 300+ webpages and at last count 250+ web containers. It compiles down to 48 MB (we only have a handful of images in it).
I’ve been giving this some thought. I have a simple web project in mind that will have many parts including creating the user account, email verification, and then having an admin interface along with a regular user interface.
Absolutely no timetable on this because it will take me several dedicated weeks to record it and clean up the video. It might be bigger than the Journal Entry project (for desktop), which is 10 hours long, that I already have in our training area at http://www.bkeeney.com/XojoTraining/xojotraining.cgi
The Web Container Controls (from August) webinar also shows you how you can create a ListBox with embedded PopupMenus. The video and example projects are here:
Actually that is not a bad question and obviously it will mean different things to different people. For the sake of fine tuning the scope, lets say:
*. 200+ simultaneous users
*. Database with 200+ tables
*. Around 250 forms: A few main forms and then, detail forms, configuration forms, results, browse, etc.
*. 50 reports
*. Few search grids
*. Consumes some external web services, such as docusign, local scanner capabilities
*. Users can upload/download documents
*. Some reports/processes will have to process and analyze millions of records to determine X
*. Lots of business logic behind it
Think Insurance, Medical, Finance or Legal apps
or what about an app that is smaller in scope but will be used by thousands at a time?
This last one is actually really important. I currently have a project that is being used by 30k people at one time.