petermichaux@gmail.com wrote:[color=blue]
> Csaba Gabor wrote:[color=green]
> >
petermichaux@gmail.com wrote:[color=darkred]
> > > So what is another way to determine the location (url) of grof.js (and
> > > burp.js) in the following example (or scriptaculous.js in that library)
> > > so that I can dynamically src the other js files in the libraries
> > > (grof2.js)? I don't want to hardcode any locations.[/color][/color][/color]
[color=blue]
> Yes, but where are the rest of the scripts? This is my big problem.
> Determining the location of the other scripts. I have the library
> installed in a top level directory ("/javascripts/") on my web app but
> I give the library to someone else they may install the library further
> down the directory tree. The gateway file for the library needs a way
> to locate all of the rest of the scripts.
>[color=green]
> > For example, you could put in properties
> > id="currentScriptFileName" and
> > onload='bootstrapIterator("nextScriptFileName")', which function you'd
> > define in your first script file.[/color]
>
> I can't chain the files together in this case. But even if I could I
> don't know the URL of the next script. I'm hoping I don't have to force[/color]
I think I'm missing something here. Who does know the URL (or more
rather, file name) of the next script(s). In other words, once the
first file in your library is loaded, either that file should know the
rest of the scripts involved, or it should know the next one only and
the next one is responsible for knowing the 3rd one's name and so on.
Or is there something else going on? I assumed it was the second of
the two possibilities I mentioned since you were mentioning that you
were ensured sequential loading. If this is off, please correct me.
Not that it really would have changed my responses, I think.
[color=blue]
> the library user into writing the whole URL in the initial script src
> tag for their installation of the library. That would feel like[/color]
So let me paraphrase what I think I read. I imagined that you had a
library (of several javascript files full of lots of fun code). And
that this library winds up on other people's servers - that is to say
that the javascript files wind up on someone's server who is intending
to use the library. Only it could be in an arbitrary location relative
to the HTML documents they are serving up. So you want them to be able
to have a minimally long src="..." in order to specify the location of
the first javascript file in the library. And that javascript file is
responsible for loading all the rest. But to do that, it needs to know
where it itself is, so that it can write a complete src for the
remaining SCRIPTS that it writes out. And it intends to do this by
finding the src for its own SCRIPT tag (and also window.location.href).
[color=blue]
> failure. There should be some workaround so the gateway script can
> identify it's own URL and use this as a basis to determine the other
> files' URLs.
>[color=green]
> > Could it be that the script loading has not settled? Perhaps you could
> > put in a
> > window.setTimeout(
> > function(){
> > var st = document.getElementsByTagName("script");
> > alert(st.length)},100);
> >
> > Does it make a difference whether you use document.write or DOM methods
> > (document.createElement...)?[/color]
>
> scriptaculous.js says that document.createElement method doesn't work
> in Safari. I haven't tried this yet but either way i still need to know
> the locations of all the script files in the library.
>
> Any other ideas about getting the script locations?[/color]
So is it not the case, that you only ever need to fish out one script
tag, really, that first one that the user/developer must code because
that will allow subsequent scripts to determine the location of all the
remaining script files?
In this case, won't placing an id=... allow that script element to be
recovered? I still think this is the one that bears most careful
examination.
<script type='text/javascript' id='PetersFunkyLibrary'
onLoad="alert(document.getElementById('PetersFunky Library').id)"
src="..."></script>
Up to some months (a year?) ago, it was the case that in FF the SCRIPT
elements sat in the HEAD element off the HTML element
(=document.documentElement). But that is evidently no longer the case,
as I am now finding the SCRIPT elements under document.body, and not
necessarily directly under (if you wrap the SCRIPT in a DIV). It seems
to me that they were happy where they used to live and I don't see the
reason for their eviction. Nevertheless, perhaps directly walking all
the elements of document.body.childNodes and checking for
..nodeName=="SCRIPT" might have a shot at finding all the script
elements in the problem browser (though I don't give it good chances if
document.body.getElementsByTagName('SCRIPT') is failing).
Csaba
