The current (Nov 2011) Dojo OAM files in Maqetta are written such that the
require attribute conflates the main library file with other dependencies, while using direct calls to
dojo.require for the remainder of the dependencies. This is an issue now that we are trying to make use of AMD loading in Dojo. We need to OAM files to better support Dojo's AMD loader; but I'd like to also ensure that the metadata stays as generic as possible and doesn't bring in implementation details.
The OpenAjax Metadata spec mentions the following, under the
Whereas we currently point
<library> to the library base directory and include the main JS file as a
require, we can instead point
<library> to the main JS file, thereby dividing it from the rest of the dependencies.
Then, any JS
<require> elements can be used in the module loader dependencies array, when the OAM file is parsed.
Module JS vs. Plain JS
There's still an issue with how OAM can differentiate between JS files that are coded as modules (AMD or CommonJS/Modules) or are just "plain" JS files. Each type is loaded differently, so the distinction is significant.
One approach would be to add a
module attribute to
<require>, whose value is a simple module spec identifier (i.e "amd", "commonjs"):
The idea is that an OAM parser that understands the
module attribute could take the
src and transform it to a module id as necessitated by the module loader (i.e. "dijit/form/Button" from the example above). An OAM parser that did not check for
module could still load the resource at the given
src the regular way (adding a
<script> tag or using XHR).
The problem with that is that module loaders don't necessarily work that way. A user can configure the module loader with "module paths", where the first segment of a module id can point to an arbitrary path on the system. So while a JS file may live at the provided
src, the module id might be something different and there might not be a clean transform from
src to the module id.
Also, we don't really know if AMD module files can be loaded in
<script> elements one after the other. There may be issues with ordering and timing in this case. After all, the point of an AMD loader is to circumvent issues with loading in
New Require Type
Therefore, in order to alleviate the issues mentioned above, the best option may be to create an entirely new type for the
For backwards compatibility, an OAM parser that didn't know about the
In order to distinguish between different module loader specs, we also added a
format attribute, whose values may be "amd" or "commonjs", ...