Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JsBindings: Asynchronous loading of XML files in JS #1251

Merged
merged 11 commits into from
Jun 29, 2021

Conversation

frericp
Copy link
Collaborator

@frericp frericp commented Jun 25, 2021

This PR adds proper support for readFromXmlString and readFromXmlFile to the JavaScript bindings, for both browsers and NodeJs. As part of that, it consolidates the way we use custom JS code in the emscripten module and cleans up the CMake file a bit.

Update #1184

@frericp
Copy link
Collaborator Author

frericp commented Jun 28, 2021

The builds are failing because I've added some files in the TestSuite folder, which seem to be picked up automatically by some of the other tests. Any suggestion where I could move these test files to instead?

I realized that NodeJS might not need any special treatment at all, since files will usually be loaded from the local filesystem, which the native (C++) functions should be capable of. I'll try to bypass all the JS code for Node and simply let the C++ function handle file loading. If that works, we can remove all code related to NodeJS and therefore simplify the implementation.

return value;
}
};
//
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum, I didnt add this header to source/JsMaterialX/JsMaterialXFormat/StrContainerTypeRegistration.h, could you add it there as well? the LICENSE thing :)

const xmlString = mx.writeToXmlString(doc, writeOptions);
expect(xmlString).to.include(includePath);
});
let mx;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, very comprehensive test suite. I'm wondering if this one is more through than the original cpp and whether it makes sense to put some of these tests there? like the cycle and the deeply nested includes. Could be in another task or PR, just wondering if it makes sense

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first three tests are stripped-down versions of a test that is run in the C++ pipeline as well. I haven't checked all of them, but I think there is also one that tests nested includes by now. Some of these JS tests might still be interesting for C++, but it's important to note that we're not testing the C++ implementation here, but the JS one. So even if the tests are duplicated in C++, they should remain here as well.

// are skipped.
const doc = mx.createDocument();
const filename = 'CustomNode.mtlx';
await mx.readFromXmlFile(doc, filename, examplesPath);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what I'm expecting from this? So, if I read the same file several times, do you get the document as it was before? Or what is added? if nothing is added can we add an assert more explicit, like the exported string is the same of the number of nodedefs are preserved?

// Read and validate the example documents as strings
const examplesWithIncludesStrings = getMtlxStrings(examplesWithIncludes, searchPath);
readAndValidateExamples(examplesWithIncludesStrings, libs,
async (document, file, sp) => {
Copy link
Collaborator

@kohakukun kohakukun Jun 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these async functions work? The async part is inside the callback, you would need to add the await aswell in the readAndValidateExamples calls 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

readAndValidateExamples has an await in front of the invoked callback.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I got what you mean. You're right. I guess it works because the code after the readAndValidateExamples calls doesn't depend on what happens inside of this function. I'll still add the awaits, though.

it('Disabling XML includes', async () => {
const doc = mx.createDocument();
const readOptions = new mx.XmlReadOptions();
console.log(readOptions);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leftover

}
pathList[i] = path;
}
if (typeof paths === 'string') {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not fan of the return value if string otherwise look into the object. In Threejs they return the modified object aswell. I would say you always return something

// Create folders if necessary.
var folders;
if (isFile) {
folders = file.substring(1, file.lastIndexOf("/")).split("/");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While reading through the code, I'm a little confuse when to use pathSep, PATH_LIST_SEPARATOR and the string literal "/". Can we substitute the use of "/" by a variable so that it is more readable when to use it? Something like "browserSep" 🤷‍♀️

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added some comments on the variables to clarify their purpose.


// Upload the initial file (string) to the WASM FS
var wasmCwd = getWasmCwd(wasmRootFolder);
var initialFileName = wasmCwd + "/ChosenToHopefullyNotClashWithAnyOtherFile123";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😅

@frericp
Copy link
Collaborator Author

frericp commented Jun 29, 2021

@bernardkwok This PR is ready to be merged, but the Codacy check complains about lines like while(--i) or if (++i < someValue). I can rewrite this, which would make the code a little more convoluted, or we ignore these issues. Whatever you prefer.

Scratch that. Turns out changing the code isn't too involved.

@frericp frericp merged commit f618a3d into adsk_contrib/dev Jun 29, 2021
@frericp frericp deleted the adsk_contrib/async_xml_loading branch June 29, 2021 12:42
ashwinbhat pushed a commit that referenced this pull request Feb 25, 2023
- Add in a file menu with hotkeys
- Add in a help menu
- Add in Viewer menu
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants