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