Add isfs support for seeing everything in a namespace

[isc-tleavitt]

To aid in migration from Studio, it would be great to be able to have an isfs folder containing a single view with everything in a namespace, ideally broken down into Classes / Routines / Other / Web Applications as it is in Studio. It would be much cleaner to have a single isfs folder with everything rather than needing to fight with filters to get "Other" (I know ?filter=* will do the trick) or define two folders, one for web application files and one for everything else. (This complicates opening files and working seamlessly between e.g. CSP files and classes.)

(I've had conversations with @isc-bsaviano about feasibility of this and it sounds tricky but maybe possible.)

[isc-bspead]

Two Thumbs WAY UP for this enhancement request ... this is probably the number one blocker for being able to quickly and easily connect to any server in our organization like we can easily do with Studio

[isc-bsaviano]

For transparency, this is what I communicated to Tim and Ben internally:

That's something I can look into. Using the existing ObjectScript Explorer to get that Studio-style tree may be possible, but getting the UX right is going to be difficult.

The problem with having everything in one ISFS folder is that I can't tell from the URI if the slashes need to be converted to dots when talking to the server about that document. The Abstract Document interface means I can't have a static list of extensions that use dots.

I'm considering this a "backlog candidate" rather than immediately looking into it because it would be a big change and getting the UX right is of utmost importance. I welcome feedback from all users. Note that we did make some improvements to the ISFS folder creation UI recently so users don't have to open the JSON to set a filter. The documentation has been updated to show the new UI.

[isc-jsmith]

This would be super useful to me - I don't usually need to look at routines, but sometimes I do have to, and with server side editing, I can either have all the code in a single "folder" of an isfs workspace which is cluttered with items I mostly don't need to see, or I can have a multi-root workspace with folders for classes, routines, and includes which seems to slow down VSCode quite a bit.

[gjsjohnmurray]

A .code-workspace file like this seems to do a pretty good job of emulating Studio's Namespace tree:

{
	"folders": [
		{
			"name": "iris:HSCUSTOM Classes",
			"uri": "isfs://iris:hscustom/?filter=*.cls"
		},
		{
			"name": "iris:HSCUSTOM Routines",
			"uri": "isfs://iris:hscustom/?filter=*.mac,*.inc,*.int"
		},
		{
			"name": "iris:HSCUSTOM CSP Files",
			"uri": "isfs://iris:hscustom/?csp=1"
		},
		{
			"name": "iris:HSCUSTOM Other",
			"uri": "isfs://iris:hscustom/?filter=*,'*.cls,'*.mac,'*.inc,'*.int"
		}
	],
	"settings": {}
}

And by appending &mapped=0 to the first two URIs you can eliminate stuff mapped into the namespace from elsewhere (not sure if Studio has an equivalent capability).

The only difference I've spotted so far is that the order of entries in The Other folder differs between Studio and VS Code.

@isc-jsmith can you provide more information about the slowdowns you've seen when doing this sort of thing?

It shouldn't be hard to add an extra button to the Server Manager tree alongside the pencil and eye ones, to add the above 4 roots to the workspace in one click. If there's a concern about this cluttering the UI it could be done by a separate extension, or made configurable by a Server Manager setting.

[isc-jsmith]

A .code-workspace file like this seems to do a pretty good job of emulating Studio's Namespace tree:

{
	"folders": [
		{
			"name": "iris:HSCUSTOM Classes",
			"uri": "isfs://iris:hscustom/?filter=*.cls"
		},
		{
			"name": "iris:HSCUSTOM Routines",
			"uri": "isfs://iris:hscustom/?filter=*.mac,*.inc,*.int"
		},
		{
			"name": "iris:HSCUSTOM CSP Files",
			"uri": "isfs://iris:hscustom/?csp=1"
		},
		{
			"name": "iris:HSCUSTOM Other",
			"uri": "isfs://iris:hscustom/?filter=*,'*.cls,'*.mac,'*.inc,'*.int"
		}
	],
	"settings": {}
}

And by appending &mapped=0 to the first two URIs you can eliminate stuff mapped into the namespace from elsewhere (not sure if Studio has an equivalent capability).

The only difference I've spotted so far is that the order of entries in The Other folder differs between Studio and VS Code.

This is what I ended up doing. The main issue with this is I can't easily change the filtering using a context menu. Most of the time I don't care about generated code and don't want to see it but some times I do (at least a couple of times a week).

@isc-jsmith can you provide more information about the slowdowns you've seen when doing this sort of thing?

I see slow downs fairly regularly but I haven't been able to pin down the cause. I'm not 100% convinced it's the extension itself, but it did seem worse after switching to multi-root server side workspaces, but in hindsight that could have been partially down to an old computer. It's been fine for a while now.

It shouldn't be hard to add an extra button to the Server Manager tree alongside the pencil and eye ones, to add the above 4 roots to the workspace in one click. If there's a concern about this cluttering the UI it could be done by a separate extension, or made configurable by a Server Manager setting.

[isc-bsaviano]

@isc-jsmith You can change the filter by right-clicking on the workspace folder in the Explorer, then selecting the Modify Server-side Workspace Folder... option:

[isc-jsmith]

Yeah, but that sends me through the whole "wizard" again and I have to click through and make sure I don't muck up the existing settings. It's replacing 1 click with several.

[isc-bsaviano]

The absolute fastest way to change that is using the Open Workspace Settings (JSON) command from the command palette and modifying the URI yourself. I assume that's what you're already doing.