The root mozile
directory contains the following sub-directories:
demos
contains demonstrations of Mozile in action.doc
contains documentation, including this documentation and API documentation generated by JSDoc.images
contains image files used by Mozile.jsunit
contains the JsUnit testing framework, which drives Mozile's unit tests.lib
contains RelaxNG schemas which are used for structured editing and validation.src
contains the JavaScript code which makes Mozile work.tests
contains the unit testing code which verifies that Mozile is working correctly.Most of these directories don't require further description, but a few do.
The layout of the src
directory corresponds to Mozile's concept of code "modules". JavaScript has many virtues as a programming language, but it also lacks many important features that we take for granted in other languages. One of these features is support for code libraries, and that means namespace support is also lacking. Because there is no built-in way to package code into libraries and import the libraries into your code, JavaScript developers have come up with their own methods and conventions.
Mozile follows the lead of JavaScript toolkit projects such as Dojo. One of the basic data types in JavaScript is the Object
, and objects can have properties which are also objects. Properties are accessed using the common "dot" notation, so we can have a hierarchy of objects such as parentObject.childObject.grandchildObject.foo
, where foo
is some property. This looks a lot like the way packages are accessed in Java, for example, and for most of our purposes it behaves the same way.
Because there are no namespaces in JavaScript, we keep Mozile's code separate from other code running in the same page by adopting a convention. We declare a global mozile
object in the page, and all of the rest of our variables will be assigned as properties of the root mozile
object or its descendants. We try to organize our code in a sensible way, like any code library would.
This is how we get Mozile's code modules. The file src/dom.js
defines the mozile.dom
object, which has as its children a bunch of properties like mozile.dom.TEXT_NODE
, and a bunch of functions like mozile.dom.insertAfter()
and mozile.dom.removeChildNodes()
. (We often use "function" and "method" as synonyms, because the usual differences between them don't make as much sense in JavaScript as in other languages.)
Also, the file src/dom/TreeWalker.js
defines an object called mozile.dom.TreeWalker
. In this way modules can have sub-modules.
The mozile
object itself is defined in src/core.js
. This file has all the code required to bootstrap Mozile. After it is loaded, the mozile.loadModule()
function is used to load other modules.
Every module file should begin with a license block, a JSDoc summary, and mozile.require()
and mozile.provide()
statements. The mozile.require()
call will make sure that an dependencies are loaded before the rest of the module is loaded. The mozile.provide()
call indicates what properties and functions the module will provide, but currently it has no real effect.
All of Mozile's testing code is kept in the tests
directory, and the JsUnit code which runs the tests is kept in the jsunit
directory.
Within the tests
directory there are sub-directories for most of the modules. The tests/code
directory is the default location for tests when they don't merit their own directory. The tests/shared
directory contains the code which is common to all the tests.
Within each sub-directory, the test files are named either after the module which they test, or specific classes, objects, or functionality which belongs to that module. The point is simply to make it clear what is being tested by the particular test file.
The overriding goal is avoid any surprises by keeping the code separated by its function and storing it where you would expect to find it.