Opened 13 years ago

Closed 11 years ago

#9349 closed enhancement (wontfix)

Support commonjs environments

Reported by: Adam Peller Owned by: Dustin Machi
Priority: high Milestone: 1.7
Component: Core Version: 1.3.0
Keywords: Cc: James Burke, alex, Eugene Lazutkin, liucougar
Blocked By: Blocking:

Description (last modified by Adam Peller)

I'm experimenting with using Dojo in Jack-JS, a Rhino-based app server that lets you write your server apps in JavaScript. It supports a community driven effort to standardize JS APIs for servers called CommonJS (formerly called serverjs)

CommonJS has a module loader that is somewhat like Dojo's own. The two don't seem to map to each other, but I think they can peacefully co-exist. A few tweaks are needed to the bootstrap to support the 'exports' free variable used to anchor references, such as the Dojo object itself. Once we're bootstrapped, we can have a special serverjs hostenv. For the purposes of getting things running on Jack, I just based it on Rhino, but hopefully we can build it on SecurableModules such that the hostenv will run in any SSJS environment.

see also #7757

Attachments (2)

serverjs.patch (11.8 KB) - added by Adam Peller 13 years ago.
hostenv_serverjs.js (3.1 KB) - added by Adam Peller 13 years ago.
updated hostenv_serverjs.js uses more ServerJS APIs -- only setTimeout remains

Download all attachments as: .zip

Change History (16)

Changed 13 years ago by Adam Peller

Attachment: serverjs.patch added

comment:1 Changed 13 years ago by James Burke

It seems like the tasks might be the following:

  • Have a serverjs_hostenv.js. This file should use plumbing similar to whatever is under serverjs's require() as far as reading files and evaling the content. Hopefully they have a wrapper for those functions and it is not serverjs-host environment specific. That would balloon the number of our _hostenv files. Maybe instead of the rhino-equivalent of "load" we can use the serverjs require() call itself to load and eval the code.
  • Make sure we can access the global object so we can attach our top-level namespaces, and set appropriately. This will allow us to properly load top-level namespaces like dojox/dijit.
  • Do we need to override the serverjs require? So, if we notice the require call is for a dojo-known namespace we do our dojo.require stuff, then we can just export that module. So if require("") we do a dojo.require("") then we do an exports = (or if we cannot overwrite the exports object, do a dojo.mixin).

That might be enough to get dojo to operate in that environment. The next thing might be able to allow people to dojo.require() serverjs modules. Maybe that is a separate ticket. I think we can get it to work by adding a "var require = dojo.require;" before the text for the module, and then set up exports to an object that is based on the dojo.require() for that module (*not* the dojo.provide call, since the module won't have one).

comment:2 Changed 13 years ago by Adam Peller

@James: you'll see my feeble attempt at a hostenv_serverjs file in the patch. I only replaced the load() call, but in my local repo I've replaced the code that does the file I/O also. Do you remember what all that stack walking was about? I don't see the scriptLibraryUri config actually used anywhere?! I do hope serverjs provides the full path of the required dojo.js file soon... I've asked for this.

This would add one hostenv which would ultimately be able to cover a wide array of server-based hostenvs, so I think it's a big win. Could get us running soon-ish on v8cgi, etc.

I'm not sure setting exports does us any good unless we consistently apply exports=* in our code. Also, it would be about supporting a new paradigm where SecurableModules? require could be used directly on a dojo module? I'm not sure I've figured out if there's a match here or not but I think what we have now lets the two systems live side-by-side, more or less.

comment:3 Changed 13 years ago by Adam Peller

Component: GeneralCore
Type: defectenhancement

comment:4 Changed 13 years ago by James Burke

peller: I saw your patch with the new hostenv. It still contained a fair amount of Java stuff though. I am hoping all the Java references go away. I saw the starting of the serverjs changes, but I figured I would try to identify what we need to change so we have a target, but I am not totally familiar with the environment yet.

As far as the path to dojo.js, I wonder, do they set some sort of environment variable for where all the scripts get loaded from? If so, maybe we can use that?

About libraryScriptUri, I have a ticket for removing it (#6912), I just have not had it on a priority list to get to it. I have not been able to find where it is used, so that should get rid of some debris in that file. libraryScriptUri was like baseUrl in the olds days as I recall, but now only baseUrl is used.

We might be able to skip the export work for now, or at least open a different ticket if/when we get there. As you say, probably as long as we can load dojo, and you can use your dojo code in a serverjs environment, that is a good first step.

Changed 13 years ago by Adam Peller

Attachment: hostenv_serverjs.js added

updated hostenv_serverjs.js uses more ServerJS APIs -- only setTimeout remains

comment:5 Changed 13 years ago by Eugene Lazutkin

Cc: Eugene Lazutkin added

comment:6 Changed 13 years ago by Mike Wilson

(this is really a nonsense post to activate cc - how is this done without adding a comment?)

comment:7 Changed 13 years ago by Adam Peller

Description: modified (diff)
Summary: Support server-js environmentsSupport commonjs environments

comment:8 Changed 13 years ago by Karl Tiedt

Mikewse, just edit the CC list and "submit changes" ;)

comment:9 Changed 13 years ago by Adam Peller

Milestone: tbdfuture

comment:10 Changed 12 years ago by Dustin Machi

Milestone: future1.5
Owner: changed from Adam Peller to Dustin Machi

I created a little commonjs wrapper package here, that works with narwhal at least, and possibly some of the other envs. I'll update this to match the work from #7757 that was agreed on.

comment:11 Changed 12 years ago by Adam Peller

Milestone: 1.51.6

comment:12 Changed 11 years ago by bill

Milestone: 1.6future

(sadly) punting seemingly abandoned ticket and meta tickets to future

comment:13 Changed 11 years ago by bill

Cc: liucougar added
Milestone: future1.7

Seems like #12357 will fix this?

comment:14 Changed 11 years ago by Dustin Machi

Resolution: wontfix
Status: newclosed

This ticket represented work that went on prior to the full amd push and has since been superceded by that set of work.

Note: See TracTickets for help on using tickets.