DojoX is an area for development of extensions to the Dojo toolkit. It acts as an incubator for new ideas, a testbed for experimental additions to the main toolkit, as well as a repository for more stable and mature extensions. Unlike Dojo and Dijit, DojoX is managed by subprojects, each of which has at least one module, a sponsor and a mission statement. [Release cycle policy TBD] The subprojects may have dependencies on Dojo and Dijit code or other subprojects in DojoX. Some subprojects may choose to keep their dependencies on Dojo minimal, perhaps only depending on Dojo Base, and remain largely toolkit agnostic. Other DojoX sub-projects directly extend Dojo or Dijit components, like the Flickr data store and dojox.color.

A DojoX subproject’s status can be found within the README file within the top directory of the subproject. README files are mandatory, and status changes must be approved by the DojoX BDFL. These are the possible states for a DojoX subproject:

experimental. A subproject which may be new or a proof of concept. It is somewhat functional but may also be highly unstable and subject to change or removal without notice.

alpha. A subproject in alpha status shows a higher level of commitment than experimental, but is still subject to change without notice. Unit tests are required, but may not all run successfully.

beta. A subproject in beta status is considered somewhat stable. API changes may occur as needed, but will be documented at release. For a subproject to be considered for beta, unit tests must all pass and full inline documentation is required.

production. A production level subproject follows the same conventions as Dojo Core and Dijit: a major release cycle and deprecation cycle is required for all incompatible API changes. i18n and a11y compliance are desirable, but not required, and will be documented in the README. An entry in these Dojo Documentation pages is required.

Classes are Capitalized, eg: newdojox.image.Lightbox, to create a Lightbox from the dojox.image project

All namespaces exist withing their project name. No classes exist in the top-level dojox namespace, with one notable exception: dojox.Grid. This Grid module is deprecated, and will be gone in 2.0. It will be replaced with dojox.grid.DataGrid

No cross-namespace pollution takes place indirectly.

There is, however, a supported convention for DojoX to add or modify functionality in Dojo or Dijit: hypens. By adding a hypen to the
module name, it is meant to be clear the module modifies something elsewhere in Dojo.

The rational is: Because the hypen is illegal in JavaScript variables, you will never be able to directly call an ext-dojo method directly, and the act of requiring it mixes the desired functionality in the appropriate place.

Contributing new projects, or patches for existing projects are covered under the same rules as Dojo and Dijit. Code must adhere to The Dojo Style Guidelines, and be covered under a Contributor License Agreement to ensure
it may be distributed. Accepting a new project or patch for an existing project is left to the discretion of the project “owner”, or in the case of top-level project, the DojoX BDFL (currently: Adam Peller)

You are obviously more than welcome to create your own projects and modules that use the Dojo Toolkit and not contribute them to directly back to DojoX. Feel free to blog, design, and otherwise innovate using the Toolkit, and release it independently, though contact us, as we would love to evangelize your efforts!

No convention currently exists for external modules in DojoX. For Dojo 2.0, the DojoX project will likely be “decoupled” and treated as entirely external through an undermined mechanism for package retrieval.