A gentle inquiry about the current activation logic of the Explorer Panel

[hsyhhssyy]

I previously opened an issue (#1665) regarding the activationEvents config of the ObjectScript extension in VS Code. Specifically, the extension activates when certain file types (like .cls, .mac, etc.) are present in the workspace. However, in a completely empty workspace, the extension doesn’t activate automatically, which means the Explorer Panel isn’t registered under the InterSystems ViewContainer.

I personally prefer using the “Choose Server and Namespace” command from the Explorer Panel to connect to a server. With the current behavior, I need to trigger the extension manually—through somewhat indirect means—just to access the Explorer Panel.

I recall that, some time ago, the ObjectScript extension did activate automatically even in an empty workspace. Could I kindly ask around which version the Server Panel and Explorer Panel were merged into the same ViewContainer? It seems logical that this merge might have introduced the behavior I’m seeing now—but I also remember my usual workflow still working for a while after the merge. Was that perhaps just my misperception?

Nowadays, all actions in the Servers Panel appear to add the server as a web folder to the current workspace. Once added, code can be browsed directly within the workspace folder structure. Given that, I’m wondering: what’s the intended use case for the Explorer Panel as a code browser these days?

[isc-bsaviano]

I personally prefer using the “Choose Server and Namespace” command from the Explorer Panel to connect to a server. With the current behavior, I need to trigger the extension manually—through somewhat indirect means—just to access the Explorer Panel.

I'm really interested to hear why you like to do this. I would expect that saving the credentials in the user or workspace settings would be preferable in almost every case.

I recall that, some time ago, the ObjectScript extension did activate automatically even in an empty workspace. Could I kindly ask around which version the Server Panel and Explorer Panel were merged into the same ViewContainer? It seems logical that this merge might have introduced the behavior I’m seeing now—but I also remember my usual workflow still working for a while after the merge. Was that perhaps just my misperception?

According to the changelog, version 2.12.0 (Jan 29th, 2024). Since I couldn't reproduce this issue the last time you reported it it would be helpful if you could identify the exact version where the behavior started so I can try to pinpoint the commit that caused it.

Nowadays, all actions in the Servers Panel appear to add the server as a web folder to the current workspace. Once added, code can be browsed directly within the workspace folder structure. Given that, I’m wondering: what’s the intended use case for the Explorer Panel as a code browser these days?

The Explorer predates server-side editing. IMO it's main use is to browse the contents of the connected server-namespace so you can see what other documents are present that aren't a part of the client-side workspace. You could accomplish the same task by adding an isfs-readonly folder to your workspace, but IMO that is less elegant because you now need a .code-workspace file instead of being able to open the folder directly. When I do client-side editing I never look at it, as the document in the client-side folder comprise the project I'm working on.

[hsyhhssyy]

I'm really interested to hear why you like to do this. I would expect that saving the credentials in the user or workspace settings would be preferable in almost every case.

The reason I’ve set things up this way is that, as a Support engineer, I organize my workspaces by case number. This helps me switch between different cases and manage their code more efficiently—especially since cases aren’t always developed and deployed in the same order, so I often need to maintain multiple active cases at once.

I prefer not to keep all cases in a single workspace, as it would become difficult to tell which code belongs to which case. Over time, this approach has led me to accumulate quite a few workspaces (hundreds or even thousands), each named after its respective case number and moved into an archive folder once the case is closed.

Because of this workflow, whenever I create a new workspace, I first create a new folder and use the “Open as VS Code Project” option via right-click. Then, I click “Choose Server and Namespace” to assign a server to that workspace.

To be honest, I haven’t come across any official documentation of standard workflows for client-side editing in VS Code, so this setup is largely based on my own needs and personal preferences.

As a result, I rarely use the Server panel. I also rely heavily on saving files locally. This allows me to keep a more detailed history of my changes beyond what’s captured in version control commits.

I think my workflow is no Client-Side Editing, because I does not add any virtual folders to my workspace.
I just put files under my workspace folder directly and organize them in sub-folders by usage.

If possible, could you please share the recommended workflow for using this extension? I’d be happy to explore adjusting my current habits to better align with the intended usage.

[hsyhhssyy]

it would be helpful if you could identify the exact version where the behavior started so I can try to pinpoint the commit that caused it.

The issue was introduced in ObjectScript Extension version 3.0.0.
I tested with version 2.12.10, and it works as expected.

Have you been able to reproduce the case in the latest version? Specifically, that preference of hiding the Servers view causes the Explorer panel to not shown from the View Container in a brand new workspace?

[isc-bsaviano]

Thanks for the explanation, that's really helpful! I had no idea you were a fellow employee due to your account name. Your workflow makes a lot of sense for the unique work that you do in support. You may be able to save some time by having a template settings.jsonthat you copy into every new workspace when you create it. That file can contain any settings that you don't want to put in your user settings, including intersystems.servers and objectscript.conn blocks that you can customize once you copy the template into the target workspace. This will probably be faster than going through the GUI.

We do have some documentation on client-side editing here. If you have any suggestions for improvement don't hesitate to give feedback through the documentation's feedback mechanism.

I tried again to reproduce your issue and this time was able to. The activation events haven't changed between 2.12.10 and 3.0.0. The diff between those versions is large, but a quick scan didn't reveal anything obvious. This is probably caused by the onView:intersystems-community_servermanager event not firing because the view is hidden. There isn't an onViewContainer activation event. I requested an onExtensionActivated event a long time ago in microsoft/vscode#146547 but there has been no action on it.

[hsyhhssyy]

We do have some documentation on client-side editing here. If you have any suggestions for improvement don't hesitate to give feedback through the documentation's feedback mechanism.

Interestingly, this article does not mention the Servers Panel at all and instead relies heavily on the Explorer Panel. As a result, it is quite natural for users to consider hiding the Server Panel when it is not immediately needed, which can then lead to the issue I encountered.

This happens because the very first step in the article is “Connect a Server to a Client-Side Workspace,” which automatically creates the settings.json file. However, if the Server Panel is not open, the Explorer Panel does not load properly, and this first step cannot be completed as described.

You mentioned manually creating settings.json in some way as a possible workaround. For developers who work with a single customer, this might be a reasonable approach. However, for developers who work with multiple customers, it is much less practical. In that case, there may be many different servers, and the corresponding files would need to be organized somewhere and then manually copied into the workspace. This is considerably more cumbersome than selecting a server through “Choose Server and Namespace.”

This is probably caused by the onView:intersystems-community_servermanager event not firing because the view is hidden.

I also thought about this reasoning and even checked the code. Initially, I suspected that in the past the extension might have been “always loaded,” and that a later version introduced a dependency on onView, which then caused this issue. However, that does not seem to be the case.

What is a bit puzzling is that in version 2.10.12, clicking the viewContainer causes the ObjectScript extension to load immediately, even when both the Servers and Projects panels (which still existed in that version) are hidden. How was this achieved? At that time, the Explorer View already belonged to the ObjectScript extension, so it is unclear why this situation did not cause any problems then.

[isc-bsaviano]

@hsyhhssyy I looked at this a little more and it's caused by #1401. The new behavior is that the Explorer and Projects Explorer are not shown by default. They are only shown if there are workspace folders that the views apply to (for example, client-side for Explorer and server-side for Projects Explorer). The goal is to hide the views when they aren't applicable to the user's workflow. I think if I change this logic to show the vies by default and then hide them after activation this should work.

[isc-bsaviano]

Hi @hsyhhssyy, can you please download and install the VSIX in the zip below and let me know if it works for you?

vscode-objectscript-3.4.1-dev.1694.vsix.zip

[hsyhhssyy]

Hi @isc-bsaviano,
I’ve tested the file, and it worked as expected!