Export/Import all AbstractDocument types as is

[isc-svelury]

We need to export .lut files (and possibly other file-types) as .xml files like we do for .dfi files. Otherwise importing the files into IRIS does not work.

[isc-tleavitt]

An alternative to this would be to use %Atelier.v1.Utils.TextServices:SetTextFromArray or even just %RoutineMgr directly to manage import of these document types.

[CraigRegester]

Agree - I fear changing the extension to XML .... as the file contents ARE XML.... it's just the extension is LUT.

I would hope to strive to stay in line as much as possible with how the ObjectScript Extension for VS Code works... though ironically I think they have an issue open for importing LUTs as well.

[isc-tleavitt]

We're torn between the history of EVERYTHING (including classes, yuck) being exported as XML and the more modern paradigm of the filename and server name matching.

Agreed with staying in line with the VSCode ObjectScript extension.

[CraigRegester]

I think the classes are being exported in a non-XML format already (UDL? this is preferred much to the yucky XML exports)

Otherwise, agree and understand.

The developer side of me loves the ObjectScript Extension in VSCode w/ Git/GitHub integration natively provided - works beautifully (GitLens on top is chefs' kiss) - but need to play both sides of the house a bit to help our non-developers (analysts) as they work on managing our lookup tables, etc strictly using the GUI.

[isc-tleavitt]

Right - from a simplicity perspective, the additional and wrappers in our XML export (even of actual XML, which at least makes more sense) are noisy / annoying. And if someday we get (e.g.) JSON-based %Studio.AbstractDocument implementations (one can hope!) it'll make no sense at all to have that XML wrapper.

[isc-tleavitt]

Another data point: the InterSystems package manager uses/assumes XML for these, (https://github.com/intersystems-community/zpm/blob/master/src/%25ZPM/ResourceProcessor/Default/Document.cls#L207 just uses $System.OBJ.Load which won't work with an "as-is" export of a %Studio.AbstractDocument type.)

Ultimately, I think the package manager should support "as-is" import/export too. I don't think this is a blocker for us doing the right thing here, but might be a reason to support both XML and "as-is" import/export based on some flag.

That's scope creep / a future enhancement, though. As a baseline let's support the export format from VSCode (i.e., "as-is").