Hi. > 1. How do I do async updates back to the qx client? Or do I have to > implement up a client driven polling mechanism?
Maybe you'd get some ideas by looking at the package qx.data.controller. I'd make a model throwing events to which the UI subscribes, and isolate all the server polling/long requests mechanism in the model. Maybe aggregate changes to the model on the server in batches, to optimize traffic. Then let the model notify the UI depending on how the UI subscribed to events. > 2. The trading system is quite complex (ie 30+ screens). I guess this could > mean a huge production javascript file. What are the options/tradeoffs in > partitioning a GUI into bitesized bits? You can use parts - http://qooxdoo.org/documentation/1.1/parts_overview. However, we found out that the size of the packaged application doesn't grow that fast. You have maybe 800 KB in one file for a hello world, then quickly reach 1 MB as you add a few classes of your own, which use some UI components, but then only slowly increase in size as you add more of your own classes - after the first few ones, all or most of the framework is included, and that's where most of the code lays. We managed to stay well below 1.5 M B with an app using a few full screens plus a few dozens (significantly more than 30) of not that simple dialogs for editing lots of different pieces of information. Load time over a normal intranet, even with servers located thousands of miles away, is only a few seconds - 1 or 2, not 5 or 10. On the other hand, loading the source version of the app in the browser (that's a thousand files or so, when counting the framework classes in), from a web server, is a lot slower. So maybe spreading your app across several parts may not actually opimize load speed. I think it's best you try before you make a decision. We're currently working on an app which includes a significantly richer UI (in the end, I suppose it will possibly come close to the size of the framework), but I'm not yet sure we will want to package it as several parts. br, flj ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
