question about loadsubscript and "js import from js" in general
Armando Stellato
I'm only two weeks old on Javascript (and, of course, Mozilla ext.
development), so apologies in advance for posting a may-be-stupid question J
When approaching javascript, I've been quite impressed by the "average" lack
of a cleanness and organization in typical web programming. However, by
reading stuff on Mozilla, I'm happy to notice that modularization and
cleanness of code are well encouraged and somewhat supported by appropriate
components in Firefox (and it seems it will be even more in FF3).
In particular, if somebody is willing to reduce to the minimum the amount of
js present inside xul files, it is able to add listeners, on command (et
sim.) attributes to XUL all via js. One fundamental aspect in proper
modularization is that, if a js file uses one library (e.g. a logging js
library), it should be able to declare something like an #include directive
in the file. It is under every aspect wrong to suppose that both files (the
original one and its required library) should be imported by the XUL file,
since the XUL file should not be aware of possible dependencies of its
required js file. If the dependency changes, this should only require code
changes in the main js and not in its calling xul.
JS does not support #include or requires directives, but Mozilla provides a
component for doing that. So, in theory, I would be able to put something
like that:
var mainLoader =
Components.classes["@mozilla.org/moz/jssubscript-loader;1"].getService(Compo
nents.interfaces.mozIJSSubScriptLoader);
const log4jsberlURL =
'chrome://semantic-turkey/content/scripts/lib/log4js(berlios)/log4js-lib.js'
;
mainLoader.loadSubScript(log4jsberl);
at the start of a file, thus loading the required lib.
To figure the whole out, I have this typical scenario. A XUL file which
statically (there's a script declaration inside it) imports a js file which
has at its start the abode code, thus importing its required log4js lib.
There are two problems with the above code:
1) The first one is related to js import from xul. I noticed that, when
you import js code from html, it immediately starts (if it acts on html
elements, better putting a windows.onload() to be sure that the js code
would find the elements, but, for example, a simple alert window should
start immediately, and this is what happens in my tests on html-imports-js).
In xul, if you import a js file, all of its functions and variable
declarations become visible in the environment, but its "free" code (don't
know how to call it, I just mean explicit code which is imperatively invoked
from the js file without being associated to a given function) does not
start (first question: is my observed difference in the behavior correct? Am
I missing something?). It is thus impossible to put the above import
solution because that code would not be ran, and if I embedded it in a
function, than that function should be called explicitly. I could put an
init() function in the js code and then call it from xul, but I do not know
if it is the best way to do that; I don't like it that much. I also looked
for other import solutions. I could use eval() on the js source, or the
RDF/IO Lib which offers an include function, but all of them are again
functions, so they should be called explicitly the same way.
second question: which is the best way to do what I need?
2) The second one is more related to using loadSubScript in general. Is
it efficient to do that? I know that Mozilla does some caching of js files,
but I do not know what happens when you load a file from loadSubScript.
I put here another scenario: I've an XMLHttpRequest in a file called
http.js, which "ajaxes" with a server to get information needed to populate
the xul interfaces of my Firefox extension. In the current version of this
file, there is a function: httpGetResult which acts a switch for processing
all the different responses got from the server.
something like that:
if(aResultCode == RESULT_OK) {
var treeList = responseXML.getElementsByTagName('Tree');
var attr = treeList[0].getAttribute('type');
if (attr == "create_cls") {
..
This function is of enormous size. I would like to clean it all, splitting
the code of all its switches on different js files. Is it convenient to put
a different loadsubscript in each switch branch? (or in sets of branches,
this is not relevant) On the one side, this way would lighten the code a
lot, thus requiring to load http.js and then only the code of the required
js file which is loaded dynamically inside the proper switch, on the other
hand, maybe that the static import from xul of the whole "old fashioned"
http.js would be faster than statically loading only its stripped version
and then dynamically loading its needed extensions
third question: which is the best pattern to handle this?
That's all. Sorry for the length of this mail, but I preferred to make it
clear along the way (at least I hope it is J )
Thanks in advance for any reply!
Armando
--------------------------------------------------
Ing. Armando Stellato, PhD
AI Research Group,
Dept. of Computer Science, Systems and Production
University of Roma, Tor Vergata
Via del Politecnico 1 00133 ROMA (ITALY)
tel: +39 06 7259 7330 (office, room A1-14);
+39 06 7259 7332 (lab)
fax: +39 06 7259 7460
e_mail: stel...@info.uniroma2.it
--------------------------------------------------
Neil Deakin
> Hi folks,
>
>
> 2) The second one is more related to using loadSubScript in general. Is
> it efficient to do that? I know that Mozilla does some caching of js files,
> but I do not know what happens when you load a file from loadSubScript.
loadSubScript does no caching. It reloads the file and parses it every
time. However, in Firefox 3, an import feature is added which can import
scripts running locally:
Components.utils.import(localurl)
The import function loads and parses the script only once.
See http://developer.mozilla.org/en/docs/JavaScript_modules for more info.
Armando Stellato
> time.
Thanks for your answer. Could you please help me also on the two other
questions? That were (I put pointers to the original mail for whole
details):
First: is it normal that js code when statically imported from XUL is not
ran, while it is when imported from html? (see mid of point 1) of my mail)
am I missing some aspect?
Second: in FF2, how would you handle the scenarios I depicted in point 1 and
2? The first one is simple:
A XUL file which statically (there's a script declaration inside it) imports
a js file (let's call it 1.js) which needs to import another js file (called
2.js). The problem is that I do not want to associate this import to a given
function of 1.js, but I would like to tell at the very start of file 1.js,
that it has to load also 2.js. Unfortunately, due to the problem of
question1, I cannot do that because no code is launched automatically from
1.js when it is imported by the xul file.
> However, in Firefox 3, an import feature is added which can
> import
> scripts running locally:
>
> Components.utils.import(localurl)
Yes, I read about that (I meant that - in my mail - when referring to better
support in FF3), but for the moment I'm looking for the best practice in
FF2.
Thanks in advance,
Armando
Neil Deakin
>> loadSubScript does no caching. It reloads the file and parses it every
>> time.
>
> Thanks for your answer. Could you please help me also on the two other
> questions? That were (I put pointers to the original mail for whole
> details):
>
> First: is it normal that js code when statically imported from XUL is not
> ran, while it is when imported from html? (see mid of point 1) of my mail)
> am I missing some aspect?
Do you have a testcase for this? The script should be executed, if I
gather from your terminology below, by 'statically imported', you mean
used with a <script> tag.
>
> Second: in FF2, how would you handle the scenarios I depicted in point 1 and
> 2? The first one is simple:
>
In Firefox 2, you would need to use loadSubScript. Another common
technique is to use an overlay that contains all of the scripts you
need, and include the overlay in each xul file, thus the scripts are
only loaded and parsed once.
Armando Stellato
Warning: (http.js).
Warning: Please read the "VirusWarning.txt" attachment(s) for more information.
> Do you have a testcase for this? The script should be executed, if I
> gather from your terminology below, by 'statically imported', you mean
> used with a <script> tag.
mmm...the test case is a big extension (6Mb) I find difficult to decouple a
short case at the moment. I'm attaching two files hoping they suffice in
making you get an idea (and that the mailing list accepts attachments :-) ):
Imports.xul imports the http.js
The initial code of http.js is commented and it contains the kind of
importing I would put at the very start of the file (for example, to tell
that this http.js has to load log4js). Anyway, the simplest test I can make
is done by uncommenting just the following line from the initial commented
code of http.js:
alert('foo');
I would expect that when Imports.xul is loaded, it is importing http.js, and
thus it should run the alert('foo') code. This is at least what happens if
http.js is being imported by an html file. Once the html page is loaded into
the browser, it loads the script and then the alert runs. This does not
happen with Imports.xul.
>
> >
> > Second: in FF2, how would you handle the scenarios I depicted in
> point 1 and
> > 2? The first one is simple:
> >
>
> In Firefox 2, you would need to use loadSubScript. Another common
> technique is to use an overlay that contains all of the scripts you
> need, and include the overlay in each xul file, thus the scripts are
> only loaded and parsed once.
This is not properly modularization, since the loading is again in charge of
xul and not of the js file, which should ideally be the only file "aware" of
what it needs (A SW Engineer would mark it as "bad cohesion"). Anyway,
thanks for the hint, which is anyway one of the "best practice" I'm
interested to learn :-)
John J. Barton
> JS does not support #include or requires directives, but Mozilla provides a
Javascript has two important modularity mechanisms, objects and
runtimes. Objects can be used like namespaces; runtimes (meaning web
page windows for example) are close to dlls. These are both active
containers: Javascript is dynamic system.
Mozilla adds components and extensions, two more runtime modules.
The Javascript tools that emulate static compile/link have many
practical problems. But their biggest problem is conceptual: they are
good tool for a different kind of language.
John.