On Wed, Apr 4, 2012 at 1:21 PM, james hedley <[email protected]> wrote: >> Iirc the number of outgoing connections is browser dependent > > Yeah in fact in Firefox you can specify it, the default is somethign like > 15. > > Something that I don't quite feel I've got a satisfactory solution to yet is > that calls come back in different orders when there's significant work done > serve side, which can result callbacks stacking up and causing delayed > effects if the user goes aound clicking like mad on things. You can manage > screen interactions accordingly, glass the screen with a spinner when you > want the user to wait (i.e. aping a synchronous call) or make some kind of > request stack to guarantee things happen in the right order.
ah. rright. that's what the whole point of the event management stuff is for, in MVC. if you want a crude version of this kind of thing, take a look in the docs/pyjs_site/index.py source code. what that does is: * first does an HTTPRequest for contents.txt * stores a copy (as a dictionary) of the response. * sends out *more* HTTPRequests, one per page * if the page was "FAQ" it sends out *more* HTTPRequests * each response is stored in a dictionary, and a page created * _only_ when the number of responses equals the expected number of responses is the web site actually "quotes loaded quotes". so the control flow of events branches out and then comes back in again. then also there is the builder example which shows how to create custom listeners (EventListener) and how to use them as a single point for reacting and responding to events, rather than having lots of global variables kicking around you just have one. it's all fascinating stuff, all dealing with the mess that you can get into if you don't take these things into account. l.
