Bit new to all this. I have been reading and playing around and I have a couple questions:
Is it better to use one web page and a series of container controls that you embed/close as needed or should each “screen” of the app be an individual web page?
Any particular advantages / disadvantage with either direction?
I am expecting a lot of screens for this app so I am not sure what the best route to go here is.
I am by no means an expert on this but from what I understand having lots of controls hidden and then shown on pages is likely to slow your app down significantly.
Dynamically adding and removing controls seems from what I gather to be the best route to go down.
You may to split test. I have a hunch that you may find webpages slightly faster. But nothing beats real life evaluation.
Our Webapplication has sometimes hundrets of containercontrols on one Page, highly nested in each other. The performance is okay, as long as your Server and your connection is fast.
Whats cools the performance down is, if you embed hundets of CC at the same time, then the DOM loading takes a few milliseconds. And also if you design your app to be sychronous, which means, that the frontend is freezing until the server is ready, then the loadingtime can increase.
I suggest you to have as little as possible synchronous processes, if you have a lot of calculation todo.
Otherwise I suggest you to have everything on one page, except of the login for security reasons.
@Rod Pascoe ~ Thanks…my question here is with dynamic controls how do you dynamically assign the logic, events, etc.?
@Michel Bujardet ~ Yep, agreed.
@Lars Lehmann ~ So you basically have two pages and then depending on what is needed load the appropriate CC. That is the route I was thinking of going. For me each CC would basically be a “window” or “page” that I would store a reference to so as not to create duplicate instances for a given session and then close that CC and open the new CC that they are going to (where appropriate). Is that more/less what you are doing?
Exactly. We even bring this further: we have a tab-system in our application, where container-controls ca be added and handled as in-app-tabs. We do this because Xojo Webapps are not cross-tab-ready for browser tabs.
So our app always handles several nearly fullscreen CCs with a bunch of controls and other CCs in it.
We simply toggle the visibility of the CCs.
Modern browser can handly thousands of
in the DOM without any performance issues, and if they’re invisible they aren’t draw anymore and doesn’t slow down the application.
But there are some restrictions and tipps:
- You shouldn’t handle mouse events or resizing events. They drastically slowing down your UI.
- Avoid that invisible CC can execute code at all. Let them only do stuff if visible, thats just an architecture and design decision.
- Look after circular references (search in the forum for that), that’ll slow down you UI.
- Design everything asynchroneous if possible.
@Lars Lehmann ~
I had not considered the issue of Xojo not being able to deal with multiple browser tabs…hmm…
So how do you do the on page tabs? Are those being handled in a toolbar?
And thank you very much for the tips and input…this is VERY helpful.
We also use CCs for this. We let each tab float in an outer CC. Each tab holds in a property a reference to its window-CC.
When the tab is about to close, we also close the related window-CC.
The floating we achieve over CSS:
Here’s a tutorial from me.
Floating is made by the CSS-Property “float: left;”. So you don’t have to fiddle the positions of the tabs, the browser makes this for you.
Here’s a screenshot how we’ve made it:
Wow. That is very cool.
As for the tutorial I went to your profile page and had already bookmarked that…just hadn’t had a chance to go through it yet.
Thank you very much for your time and guidance. This has easily saved me days of time and maybe even weeks.