Re: Out of order JS file execution in WebKit

Hi

just to let you know that I've experimented with the dynamic dependency 
loading of JS modules so far, that I could ensure the inorder loading of 
the delivered modules in the browser. With this code in place it was 
exactly as one can deduce from your description below Tristan - it's 
time for another bite in the butt, because the server widget lives with 
the then (probably) false assumption, that the client code is up and 
running.

The only solution for me right now due to workload is to move the 
imports to the LivePage's JS code, having them kind of preloaded. This 
seems at the time acceptable, I'll give your suggestions another try, 
when I see the end of that current stretch of work.

Moving the imports then to their proper place after the fix is in place 
can be done in a later release of my code.

The reason I'm interested into doing this is I'm working on RIAs now 
with a crossbreed of qooxdoo and nevow/athena, meaning with the qooxdoo 
framework  ( http://www.qooxdoo.org ) you have everything in place to 
write really cool GUIs without even touching CSS/HTML for all browsers 
up from IE6 and with nevow/athena the whole server/backend programming 
is really a breeze.
Having the dynamic load of JS modules according to their usage would be 
a really great thing...

Mahalo, Werner

Tristan Seligmann wrote:
> On Thu, Apr 15, 2010 at 8:10 AM, Werner Thie <[email protected]> wrote:
>> Tristan, can you give me a pointer for attacking this problem, I like
> 
> Hmm, let's see. In order to serialise a widget for dynamic
> instantiation, LIveElement._structured() is called. This, in turn,
> flattens the element to get the markup; it also uses context.call to
> set up lists, including 'requiredModules', which the liveElement
> renderer mutates during the course of rendering. This allows it to
> collect a list of all modules required by the widget and any of its
> children. The list of dependencies is constructed by calling
> allDependencies() on the relevant module, and then filtering it with
> LivePage._shouldInclude(). _shouldInclude keeps a list of all modules
> it has ever been called with, and returns False if one of those
> modules is passed in, otherwise True (and adds it to the list); thus,
> each module will only be imported once.
> 
> For static instantiation, this is exactly what we want, as modules
> will be loaded in the correct order, and only once; I'm not sure what
> the best way to fix this for dynamic instantiation is. One way to do
> it would be to force the client-side code to load modules serially;
> this would ensure that they're loaded in the correct order, but this
> may affect network performance adversely. I think a better solution
> would actually be something similar to what was already discussed in
> this thread; although, most of the pieces are already in place.
> 
> Scripts are loaded in
> Nevow.Athena.Widget._addChildWidgetFromComponents, using
> Divmod.Runtime.theRuntime.loadScript(). The implementation differs
> between runtimes, but in all cases, it returns a Deferred that only
> fires once the module has actually been loaded. This is used to delay
> the actual instantiation of the widget until the dependent modules
> have been loaded. My suggestion would involve adding a loadScript()
> method on the page widget: the first time it's called, it would fire
> off the real loadScript() call; if called while the script is still
> being loaded, it would return another deferred that fires when the
> script has loaded; if called after the script has loaded, it would
> return a deferred that fires immediately. The server-side code would
> be changed to not filter the dependencies list through _shouldInclude
> in the dynamic instantiation case (by adding a flag parameter to the
> involved methods, I guess?), so that loadScript() would be called for
> all of the dependencies, not just the ones that have never been
> loaded. The page setup code would probably need to pass a list of
> statically loaded modules to the page widget, so that it knows that
> they're already loaded.
> 
> Hope that helps; I wrote this based on a cursory reexamination of the
> code in question, along with vague recollections from the last time I
> looked at the code, so I may have some of the details wrong, but
> hopefully this is enough to point you in the right direction.