How to control auto naming when git structure differs from IRIS structure?

[jer-war]

Question about the naming of classes and routines:

The structure we have in Git is like this:

\cls
\cls\Package1\class1.cls
\cls\Package2\class2.cls
\rtn
\rtn\routine1.mac
\rtn\routine2.mac

In IRIS, these are stored like this:

Package1\class1.cls
Package2\class2.cls
routine1.mac
routine2.mac

Currently we're using this and it has a mapping table for routines and classes:
https://openexchange.intersystems.com/package/Embedded-Git-1

We're moving to use VS code with client-side editing using this vscode-objectscript extension.

When creating a new class or routine in VS code, the name is set to rtn.newRoutine1 or cls.Package1.newClass1 in the header and therefore gets saved into a new folder in IRIS, so the end result in IRIS looks like this:

Package1\class1.cls
Package2\class2.cls
cls\Package1\newClass1.cls
routine1.mac
routine2.mac
rtn\newRoutine1.mac

I know that if you change the name on the first line to remove cls. and rtn. before first saving and then save, they get saved to the correct place, but I was wondering if there was a way to control this in the extension?

I can see there are some settings regarding the naming that refer to the export settings.
I've experimented and found this works but only for rtn or cls (as per the "folder" setting), not both at the same time.
However, this really doesn't seem to be the right way to do this and probably not the intention:

"objectscript.export": {
	"folder": "rtn",
	"addCategory": false,
	"map": {},
	"atelier": true,
	"generated": false,
	"filter": "",
	"exactFilter": "",
	"category": "*",
	"maxConcurrentConnections": 0,
	"mapped": true
},

Any suggestions other than changing the structure in the Git repo?

[isc-bsaviano]

Hi @jer-war, that's a great question! You are correct that the objectscript.export settings are used for the automatic header generation as well as for exporting. Here's what they should be for your current workspace structure.

"objectscript.export": {
	"folder": "", // Empty string because there's no intermediate folder between your workspace root and the sources (like "src")
	"addCategory": true, // You are using the cls and rtn subfolders for now
	"map": {},
	"atelier": true,
	"generated": false,
	"filter": "",
	"exactFilter": "",
	"category": "*",
	"maxConcurrentConnections": 0,
	"mapped": true
},

Note that these settings are not used for syncing classes and routines to the server. In that case the extension will use the name that's in the text regardless of the file path. You do not need to change your repository structure.

[jer-war]

Right clicking on the rtn folder or the package folder and New File, then typing the name like abc.mac and pressing return.
I'll try and get a screenshot a bit later on.

[isc-bsaviano]

I've opened a PR with a fix. You can test it out using the version of the extension in this zip archive.
vscode-objectscript-3.0.5-dev.1604.vsix.zip

[jer-war]

That was fast!
I've just tried it. It worked for the classes but not for the routine. I got this as the header:

ROUTINE rtn.abc 
rtnabc ;

[isc-bsaviano]

I just checked the code and that's not working because we don't have a rtn category. The default categories are cls, int, inc, mac, dfi, oth. The addCategory setting accepts an object value instead of just a boolean. This worked for me:

"objectscript.export": {
	"folder": "",
	"addCategory": {
            "mac": "rtn",
            "int": "rtn",
            "inc": "rtn",
        },
	"map": {},
	"atelier": true,
	"generated": false,
	"filter": "",
	"exactFilter": "",
	"category": "*",
	"maxConcurrentConnections": 0,
	"mapped": true
},

This will override the defaults for mac, int and inc files but will still use the defaults for everything else. This use of addCategory is undocumented but should work.

[jer-war]

Excellent, yes it works. But I had to also add the classes otherwise I got "cls." at the start of the name:
"cls": "cls"
Thanks a lot for the rapid responses. When might the fix get released in an official version?

[isc-bsaviano]

We just did a release on Monday, so even if the PR gets approved soon we probably won't do a release for another week or so to catch any other issues.