ServerJS/Modules/Environment: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
m (Updated regarding the System proposal and certain evolutions of the File System API that imply name changes here.)
Line 1: Line 1:
'''There has been no discussion of this proposal.'''
Any members of a specified object (including modules, or enumerated argument options) that are not reserved by the specification must be named with "x" as their first term and a vendor-specific label as their second term, like "require.xChironCurryId" or "environment.xCajaDomita".
Any members of a specified object (including modules, or enumerated argument options) that are not reserved by the specification must be named with "x" as their first term and a vendor-specific label as their second term, like "require.xChironCurryId" or "environment.xCajaDomita".
'''This page is currently out of date, due to the new system object/class proposals.'''


== The Require Function/Object ==
== The Require Function/Object ==
Line 8: Line 8:
* loader: the "require" object MAY have a "loader" member that is an interface to the object used by "require" to acquire module factory functions.  Tampering with this variable must not alter the behavior of "require".
* loader: the "require" object MAY have a "loader" member that is an interface to the object used by "require" to acquire module factory functions.  Tampering with this variable must not alter the behavior of "require".
* main: the "require" object MAY have an "main" member that is the module ID of the module that was the entry point for this sandbox.  Thus the common Python idiom <tt>if __name__ == '__main__':</tt> would be <tt>if (require.id == require.main)</tt>, except that this strategy avoids the problem of double loading the main module if it's referred to elsewhere by its real name.
* main: the "require" object MAY have an "main" member that is the module ID of the module that was the entry point for this sandbox.  Thus the common Python idiom <tt>if __name__ == '__main__':</tt> would be <tt>if (require.id == require.main)</tt>, except that this strategy avoids the problem of double loading the main module if it's referred to elsewhere by its real name.
== The Environment Object ==
A module receives an "environment" variable that is an Object.
* print: The "environment" MAY have a "print" function that accepts a "message" and an optional "label" String.
** The label MAY be one of "log", "warn", "error", "pass", "fail".
** Any other, unspecified label MUST be in lower-case and begin with "x" and a vendor-specific label like "x-v8cgi-database".
* is: any member that has "is" as its first term is reserved for vendor and platform checks like "isRhino", "isJavaScriptCore", "isSpidermonkey", "isBrowser", &c.
* window: the "environment" MAY contain the global "window" object in permissive browser environments
* args: an optional Array of Strings representing the process arguments.
* global: the "environment" MAY contain a reference to the global object in permissive environments
* posix: reserved for a posix subsystem interface
* fs: reserved for a securable file system interface
* dom: reserved for a securable dom interface


== A Loader Object ==
== A Loader Object ==
Line 33: Line 17:
** a module text MUST be a string that conforms to a JavaScript "program" construction.
** a module text MUST be a string that conforms to a JavaScript "program" construction.
* resolve: a module loader, if present, MUST provide a "resolve" method that accepts a module identifier (that may be a relative module identifier) and optionally a base module identifier (that must be an absolute module identifier) and returns the corresponding absolute identifier of the former.
* resolve: a module loader, if present, MUST provide a "resolve" method that accepts a module identifier (that may be a relative module identifier) and optionally a base module identifier (that must be an absolute module identifier) and returns the corresponding absolute identifier of the former.
* normalize: a module loader, if present, MUST provide a "normalize" method that accepts an absolute module identifier and returns that identifier in its canonical form.  Normalize MAY be an identity relation.
* canonical: a module loader, if present, MUST provide a "normalize" method that accepts an absolute module identifier and returns that identifier in its canonical form.  "canonical" MAY be an identity relation. "canonical" may return an opaque reference object to prevent information about the underlying file system from leaking into a sandbox.
* path: a module loader, if present, MAY provide a path member that must be an Array.  The contents of each element of the array are implementation-specific.
* extensions: a module loader, if present, MAY provide an array of file extensions that the loader must accept (in order of priority from highest to lowest) for JavaScript module files.

Revision as of 08:42, 11 April 2009

There has been no discussion of this proposal.

Any members of a specified object (including modules, or enumerated argument options) that are not reserved by the specification must be named with "x" as their first term and a vendor-specific label as their second term, like "require.xChironCurryId" or "environment.xCajaDomita".

The Require Function/Object

  • id: the "require" object MAY have an "id" member that must be the normalized identifier of the current module
  • loader: the "require" object MAY have a "loader" member that is an interface to the object used by "require" to acquire module factory functions. Tampering with this variable must not alter the behavior of "require".
  • main: the "require" object MAY have an "main" member that is the module ID of the module that was the entry point for this sandbox. Thus the common Python idiom if __name__ == '__main__': would be if (require.id == require.main), except that this strategy avoids the problem of double loading the main module if it's referred to elsewhere by its real name.

A Loader Object

  • load: the "loader" object, if present, MUST have a "load" method that returns a module factory function.
    • a module factory function MUST accept "require", "exports", and "environment" as its arguments.
  • fetch: a module loader, if present, must provide a "fetch" method that returns the text of a module for a given normalized, fully-qualified, absolute module identifier.
  • evaluate: a module loader, if present, must provide an "evaluate" method that accepts a module text and returns a module factory function
    • a module text MUST be a string that conforms to a JavaScript "program" construction.
  • resolve: a module loader, if present, MUST provide a "resolve" method that accepts a module identifier (that may be a relative module identifier) and optionally a base module identifier (that must be an absolute module identifier) and returns the corresponding absolute identifier of the former.
  • canonical: a module loader, if present, MUST provide a "normalize" method that accepts an absolute module identifier and returns that identifier in its canonical form. "canonical" MAY be an identity relation. "canonical" may return an opaque reference object to prevent information about the underlying file system from leaking into a sandbox.
Retrieved from "https://wiki.mozilla.org/index.php?title=ServerJS/Modules/Environment&oldid=139568"