When reading through the articles it seems to me that the majority prefers to create web apps by having one (or at least few) web pages in which they load 50, 100 or even 200 containers. They then swap them in and out as required.
I’m currently developing a larger app, which would indeed end up with hundreds of such containers. Because it is still time to change my application design, I’d like to know whether my web-page approach with few containers is less favourable. I have selected this approach because I felt that loading smaller pieces like web pages would consume less bandwidth at a time and I’m indeed impressed by the short response times. My app is behaving like a local GUI, no difference, really, even if I access the server over an old-fashioned 3 Mbit ADSL with only 768 kbit/s outgoing bandwidth from the server’s site.
My pattern involves a large session variable area to share the data across the webpages. Most of these data are copies of the objects in use. I am using containers only for displaying same content that appears on several webpages. One advantage that I think that multiple webpages have is that it is a bit easier to create the GUI controls in the IDE.
So, is all this a matter of taste or what are the ultimate advantages of using the container-centric approach of design?
[quote=93640:@Andreas Leitzbach]So, is all this a matter of taste or what are the ultimate advantages of using the container-centric approach of design?
[/quote]
Taste, plus some landmines. If you use containers, and dynamically instantiate them right now, you are fairly likely to run into Javascript errors, as commands to modify the new instances sometimes arrive at the browser before commands to create it.
Showing and hiding lots of static containers can consume lots of precious RAM in the browser. Mobile Safari is the most limiting and you’ll find iPads the most problematic. If your full interface doesn’t run well on an iPad, you may need to simplify it for that device.
[quote=93642:@Brad Hutchings]If you use containers, and dynamically instantiate them right now, you are fairly likely to run into Javascript errors, as commands to modify the new instances sometimes arrive at the browser before commands to create it.
.[/quote]
As Brad knows - this is causing me grief in a control we’ve spent a lot of time/effort/money on!
[quote=93654:@Michel Bujardet]A page structure is probably a whole lot easier to maintain. Dozens of containers on top of each other can become quite messy.
[/quote]
At design time, you can make them small, put invisible labels top left to identify them, position them to not overlap. Move into place and show at runtime.
I thought the times were over when we had to think about client RAM…
Thanks for the advise. Currently, my app behaves well on an iPad 2, but for sure I will monitor this more closely, now.
BTW: What is Mobile Safari’s RAM limitation? 64 KB?
Then it defeats all notion of Wysiwyg design allowed by the IDE. I maybe coming from the Basica era when we designed UI entirely in code, I find it counter productive to do that in a modern UI.
It is thousand times humanly natural to simply place controls visually on a page. Or move them around during maintenance without having to chase the settings in the code.
[quote=93669:@Michel Bujardet]Then it defeats all notion of Wysiwyg design allowed by the IDE. I maybe coming from the Basica era when we designed UI entirely in code, I find it counter productive to do that in a modern UI.
[/quote]
It actually only defeats 97% of the notion. I have measured this.
As far as this topic goes, I find that it depends on the app. We did an app internally recently which used both techniques to accomplish different things.
For instance… the app we did for XDC attendees had panels that slid in from the left and the right. Those were done as WebContainers, but each page (Events, Maps, News and Las Vegas) was a completely separate WebPage. We found it a lot easier to keep track of what code went where. Besides the fact that it makes having multiple engineers working on the project a little easier with less conflicts. As I said earlier, it’s a matter of preference and experience.
