Re: Out of order JS file execution in WebKit

Werner Thie <[email protected]> Mon, 12 Apr 2010 20:53:52 +0200
Newsgroups gmane.comp.python.quotient.dev
Organization THIEngineering AG
Message-ID <[email protected]>
This definitely makes sense. I got the sinking feeling that I'm loosing 
this really great and simple extension of JS and the whole nevow/athena 
LivePage ecosystem too when I encountered this WebKit problem first. If 
you could elaborate on where to bring in the wrapper func you proposed I 
would be more than happy.

Cheers, Werner

On 12.04.2010 20:37, [email protected] wrote:
> On 06:23 pm, [email protected] wrote:
>> Hi
>>
>> Seems that the quest for more speed in JS execution goes into the next
>> round. WebKit does not load and execute JS files in the order they are
>> specified either by '// include' or in the header of the LivePage.
>>
>> The problems I observed were that depending on load/response time my
>> LivePage based RIAs sometimes worked perfectly and sometimes simply
>> stopped working at certain stages in the WebKit based browsers.
>>
>> After some digging and inserting alert's in the JS files before
>> creating
>> a new class, the alerts showed that base classes were sometimes empty
>> and therefore the class trying to inherit died.
>>
>> A simple solution was to push the '// include' of the base classes back
>> to some early point when loading the initial page, the after wards
>> injected LiveElements then do find their base classes because
>> everything
>> is settled by then.
>>
>> I'm not familiar enough with the import system used by nevow/athena to
>> see a path for a solution but maybe somebody with the knowledge can
>> enlighten me if more refined solution could be built into nevow/athena.
>>
>> Question: Would it be feasible to extend the '// include' system such
>> that it can be guaranteed that a following constructor for YYY can rely
>> on the base class XXX being present?
>
> There's no need to extend it.  This is exactly how it's supposed to
> work.
>
> The question is how to make the implementation work properly on WebKit,
> which is violating an assumption being made.
>
> One approach might be to have Athena wrap the entire contents of each js
> module in something like this:
>
>      waitForModules(
>          ["Nevow.Athena", "common.xxx"],
>          function() {
>              // import Nevow.Athena
>              // import common.xxx
>
>              // the rest of the original js module
>
>              // This call inserted, perhaps not lexically here, but
>              // somewhere which gives equivalent ordering.
>              moduleLoaded("the name of this module");
>          });
>
> waitForModules and moduleLoaded would use a simple event-based system so
> that the function given to waitForModules would never be called until
> all of the necessary modules had been evaluated.
>
> This would let the modules be loaded in parallel or out of order or
> however (wrong?) WebKit wants to do things, but still guarantee the
> ordering that Athena is supposed to be guaranteeing.
>
> If this idea makes sense, I can go into more detail about what the
> implementation might look like.
>
> Jean-Paul
>
> _______________________________________________
> Divmod-dev mailing list
> [email protected]
> http://divmod.org/cgi-bin/mailman/listinfo/divmod-dev