Project

Profile

Help

Forums » General »

Using an object other than the global or window object as JavaScript context

Added by Michael Kay about 4 years ago

From Gustavo Oga:

The second issue is that when using ES imports in node.js the global or window object is not readily available as usual: https://nodejs.org/api/esm.html#esm_enabling

My solution to this was to create a window alias on the global object:

global["window"] = global

... with ES modules, and without this "hack", Saxon/JS is not able to find neither "global" nor "window". Other than a "fix" in Saxon/JS for this issue, I'm thinking it would be more convenient to be able to pass an explicit context to the transform function:

const context = {
  square: function (x) { return String(x*x) } 
};


SaxonJS.transform({
  jsContext: context // now only "square" is available to be called.
});

That would also be a nice addon to allow controlling what kind of functions could be called from the XSL with the js:* syntax.

Thank you,

E.


Replies (3)

Please register to reply

RE: Using an object other than the global or window object as JavaScript context - Added by Michael Kay about 4 years ago

I'm sorry, Im having trouble understanding exactly what you want to achieve here. Could you give an example? Why do you want to use the global object -- isn't this something that's usually best avoided?

RE: Using an object other than the global or window object as JavaScript context - Added by Gustavo Oga about 4 years ago

Why do you want to use the global object -- isn't this something that's usually best avoided?

This is exactly my point.

It seems my explanation wasn't clear enough. I created a test case so you can clone and check, if it helps:

See gist here: https://gist.github.com/EmmanuelOga/5f4cc30f73d7b09398349b48382d3514

Or clone it: $ git clone https://gist.github.com/5f4cc30f73d7b09398349b48382d3514.git

If you try to run that you'll see it fail as described in the README.md https://gist.github.com/EmmanuelOga/5f4cc30f73d7b09398349b48382d3514#file-readme-md

Commenting out this line "fixes" the issue:

global["window"] = {extensionFunction};

In Saxon-HE, one has to register extension functions before they can be called. I'm proposing doing the same here, except that instead of registering a function, one would register the global or window object from the point of view of the xsl script:

 const myContext = {extensionFunction};
 await SaxonJS.transform(({ jsContext: myContext });
 // Now SaxonJS can find extensionFunction, without polluting the global object!

RE: Using an object other than the global or window object as JavaScript context - Added by Gustavo Oga about 4 years ago

I just discovered the reason SaxonJS is looking for window is because I'm setting:

{ stylesheetBaseURI: "https://localhost" }

as SaxonJS.transform() option... I think SaxonJS then thinks we are on a browser.

The interesting part is that I'm trying to solve my other issue about requesting content asynchronously, and it seems SaxonJS only wants to perform http requests for ixsl:schedule-action directives on the browser side (why? It should be ok to perform an http request on the server side, just depending on the document uri scheme)

    (1-3/3)

    Please register to reply