[Bese-devel] javascript

[Lou Vanek]

Attila Lendvai wrote:

>> How do you delay-eval the javascript scripts in the ajax branch?
>> It's not being done in the main trunk so I added function wrappers
>> around all javascript scripts and call them (via javascript) after
>> the page has finished loading (and after dojo.js has finished loading).
>> If I don't do this then I get errors indicating the 'dojo' variable
>> is undefined, which it is since the dojo file usually hasn't finished
>> downloading until after the page has fully loaded. (At least upon
>> first-load, when dojo hasn't made its way into the browser cache yet.)
> 
> 
> well, i'm not a js guru, but this is how one of my page looks like:
> 
> <script type="text/javascript">
> // <![CDATA[
> djConfig =
> { isDebug : true,
>  baseLoaderUri : '/cocoma/dojo/' }
> // ]]></script
> 
>> <script type="text/javascript" src="/cocoma/dojo/dojo.js"></script
>> <script type="text/javascript" 
>> src="/cocoma/ucw/js/per-application.js"></script
>> <script type="text/javascript" src="/cocoma/dwim-static.js"></script
> 
> 
> and i think that script tags should be executed in order. somebody
> correct me if i'm wrong (but then i'll give up all hope in all www
> standards) please check and/or send what it looks like in your pages.

Yes, javascript is executed in order, but asynchronously in some cases.
Specifically, for 'src="/.../dojo.js"', the (asynchronous) call is made back to the
server for the dojo.js file, but the js continues to be evaluated in the
browser. If there is a variable client-side that is defined in dojo.js
then an error is thrown, at least on the windows platform--maybe things
are different on linux, or all your js files are previously cached
client-side. To test this, clear all your caches and then try to do
a simple 'alert(dojo);' and dojo returns null on windows if the script
is executed prior to the page finishing its load.


> (dojo needs its debug configuration created before it is loaded)

This debug configuration data is being evaluated prior to dojo being loaded, which
is true. I'm asking about the opposite situation: client-side variables
that rely upon dojo.js being loaded first.


> as with the caching of the parenscript: they are generated at the
> first request and cached on the server until the lisp file is touched.
> it's sent with some cache headers, take a look at
> parenscript-dispatcher and server-sequence. 

Not interested in parenscript, per se. Interested in ensuring that
dojo's variables are loaded and defined before the parenscript-generated code
is evaluated client-side.


i'd be more than happy if
> you could fix any possibble issues with cache headers with ie or
> opera.

I'll show you want I've done in another email.
I'm amazed that you don't have this problem on linux.


>> BTW, here are some of my latest dojo tests:
>>
>> o  firefox properly caches dojo and does not try to load it again
>> o  IE6 gets confused and tries to load it once per page
>> o  Opera 9 is utterly hopeless and asks for dojo twice per page load.
>>     Opera is also javascript-challenged and so I've pretty much given
>>     up hope trying to get my scripts to run on it.
> 
> 
> this is my log with opera 8.5 on linux at first load (and after a very
> quick test all ajax stuff works):
> 
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.ico"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/treemenu.css"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim.css"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/ucw/ucw.css"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/dojo.js"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dojo/src/debug.js"
> 00:54 UCW.BACKEND/+INFO+: Handling request for
> "/cocoma/ucw/js/per-application.js"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/dwim-static.js"
> 00:54 UCW.BACKEND/+INFO+: Handling request for "/cocoma/cocoma.css"
> 00:54 UCW.BACKEND/+INFO+: Handling request for
> "/cocoma/ucw/images/collapsible-off.png"
> 00:54 UCW.BACKEND/+INFO+: Handling request for
> "/cocoma/ucw/images/collapsible-on.png"

Hmm, apparently Opera 9-Windows is more brain damaged than Opera 8.5-Linux.

>> This was tested on winxp.
>>
>> Part of the problem was that dojo.js was being included twice in the 
>> response
>> headers but that's easy to fix, and the above test results still apply.
> 
> 
> is it with the stock ucw examples or with a custom application?  

Custom. Had to fix a lot of small things. For example, DOCTYPE was
being included twice on every page.

stuff
> seems to be working here with 8.51 opera and a recent ff.

On linux.
FF works great on windows, too. FF is the only browser on
windows that i have tested which is honoring file expiration dates.


> - attila
> 
> (alias 101 on irc &no 'its not lisp code :)
> 

Lou Vanek