Mozile's Organization

Mozile Directories

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.

Mozile Modules

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.

Mozile Tests

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.