Modules and Scopes in Helma NGThe javascript import features in Helma NG try to loosely imitate the semantics of python's import statement in order to allow applications to be written in a truly modular way. The magic of python's import statement is that a script never has to do anything special in order to avoid name clashes with other scripts, because every script lives in its one top level scope by default. To sum it up:
ImplementationHelma NG implements this by using a separate top-level scope for each loaded script file, using a shared top-level scope as prototype. A simplistic implementation of most of the behaviour described above in the Rhino shell may look like this:
Of course, Helma NG also takes care of script reloading and stuff, and the shared module scope is really a per-thread scope that uses a really-shared scope for the really-shared stuff. ExampleSuppose there is a Javascript file called
Then consider the following statements in another script file:
Note that the functions in helma/database.js do not care in which namespace they are loaded. They only see what is defined in their local file, and in the global scope shared by all modules. The scope that loaded the module is absolutely invisible to the loaded module! Also note that the getConnection() function in the last example can still access the Connection() constructor although it's not included in the importFromModule(). That's the power of closures! Pages linking to this page: wiki |
navigation
Download
Community
Weblog
Mailing Lists
IRC Channel
Documentation
Introductions
Tools
Reference
Project
Roadmap
Bug Reporting
Source
Helma NG Wiki
Wiki
Tags
Updates
Related Projects
Sites using Helma
Shop
search
tags for this page
all tags
Tagsapps (1) bugs (2) class (1) community (2) compatibility (1) concurrency (1) continuations (2) Documentation (5) Documentation ORM (0) dogfood (1) formatting (1) gobi (1) helma (6) helma 1.6 (13) helma 1.7 (8) helma 2 (13) helma ng (7) hopobject (1) html (1) inheritance (5) introspection (1) java (2) javascript (5) jetty (1) JSDoc (1) lazy (1) marius person (1) metaprogramming (2) modules (3) oop (1) organization (2) ORM (2) parsing (1) project (2) projects (1) prototype (1) Rabbit (2) REPL (1) rhino (4) roadmap (3) shell (1) shop (0) Skin Rendering (5) Snippets (1) source svn (1) sugar (3) templates (13) testing (4) Tobi (7) tobi repl shell introspection (0) xml (1) Pages linking to this page: Wiki Overview Text Draft pages linking here
|
Comments
#1 by maks at 2008/04/17 03:56This looks very nice, but it doesn't seem to be in helma2 svn trunk yet (as of 17/4/2008)?
#2 by matthias at 2008/04/24 18:58can you explain where the modules have to / may be located, and how i can influence that. thanks.
#3 by hannes at 2008/04/24 20:22Matthias: have a look at the README.txt. Quoting from there:
Helma first tries to resolve the path relative to the location of the module calling this method. If that fails, it looks for the resource in the repository path, which usually consists of the current directory (shell) or app directory (web apps) and the modules directory.
The module path can be set using the helma.modulepath property:
#4 by matthias at 2008/04/25 03:53Thanks for the pointer. I guess that this will be more elegant in a future version (no shell parameter)
Another comment: I would prefer importModule("helma/database") over importModule("helma.database") -> this would resolve the problem, that you can't have dots in file- or foldernames (which is common for libraries)
And a question / request: Wildcards to load whole folders: Have you any plans / ideas how to support this?
#5 by hannes at 2008/04/25 12:24Yes, it would be possible to use slashes as path separator in importModule. I'd then prefer to also include the .js suffix: importModule('helma/database.js'). The idea with the dot is that it is platform agnostic, plus it's the way python does it. But I think slashes are supported/recognized enough even on windows these days :-)
Regarding wildcards: they're supported as second argument to importFromModule, i.e. to import all properties from the loaded module into the current scope. They currently aren't supported for the other import functions, i.e. to import all modules from a given directory.