> 1. How do I do async updates back to the qx client? Or do I have to
> implement up a client driven polling mechanism?
Yes. As there is no reversing of client - server roles in HTTP, if you
want to implement server-driven changes, the client either has to send a
request for updates periodiacally (polling), or by opening a request
that the server will answer only when an update is available (so called
"long polling"), where the connection is kept open for an potentially
unforeseeable time. As connections are sort of precious on the browser,
most people implement a mix of both.
> 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?
There is a concept in qooxdoo whereby you partition your application
into "parts" (dialogs, screens, ...) [1] which are then only loaded on
demand. The win is that your initial app download can be much smaller,
therefore app startup is faster, and you save the memory footprint for
parts that are never loaded.
The tradeoff is that you have to "instrument" your code with the loading
requests for the parts (using qx.io.PartLoader.require). That means
there is no simple switching forth and back between using parts and not
using parts (although you can achieve that by using compile time flags
("settings" in qooxdoo parlance)).
> PS: C'mon, Engerland!
We were the lucky ones this time ;). I know, the tricky second goal of
England...
Cheers,
Thomas
[1] http://qooxdoo.org/documentation/1.1/parts_overview
------------------------------------------------------------------------------
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
