New post
Announcement
· Aug 7

Do you use client-side editing in VS Code? If so, we want your feedback!

#Development Environment #Git #Open Source #Source Control #Tools #VSCode #InterSystems IRIS #InterSystems IRIS for Health

The VS Code extension development team is looking for beta testers to provide feedback on a proposed overhaul of the client-side editing workflow. The full list of changes can be found in the GitHub pull request description. Here are the highlights:

  • Support the use of client-side editing in any non-isfs workspace folder, not just folders in your local file system. For example, with VS Code Remote Development.
  • Create an index of all Classes, MAC and INT routines, and Include files inside non-isfs workspace folders. This will be used to determine the URI of classes and routines (for example, for Go To Definition). When the last file associated with a given class or routine is deleted, the class or routine will be deleted on the server.
  • Automatically sync all file changes, creations and deletions in client-side workspace folders with the connected server. This can be turned off using the new objectscript.syncLocalChanges setting. This new setting replaces the old objectscript.importOnSave setting, which is no longer needed. If objectscript.importOnSave was set to false, the extension will set objectscript.syncLocalChanges to false upon activation so no user migration is required.
  • Automatically show and hide the InterSystems Explorer and Projects Explorer views based on the folders in the workspace. InterSystems Explorer is only shown if there is at least one non-isfs workspace folder. Projects Explorer is only shown if there is at least one isfs folder. This replaces the objectscript.showExplorer setting.
  • Change the default value of the objectscript.explorer.alwaysShowServerCopy setting to true. The InterSystems Explorer should always show the server copy since the local copy can be opened from the files explorer.
  • Change the default value of the objectscript.autoAdjustName setting to false. Now that we have an index of the workspace, we no longer require that a document's name match the file path for the extensions to find it.
  • Cache the list of Studio Abstract Document extensions that are supported for each server connection so we can properly import them from client-side folders. Importing abstract documents is now independent of the objectscript.export settings, except for DFI’s which still check the export settings to preserve the current path-splitting behavior. Any file within a workspace folder that has a supported abstract document extension will be imported with the last part of the path used as the server name (except for DFI’s that match the export settings).

In addition to general feedback on the changes, there are four design questions that have yet to be answered:

  1. Do any users want the InterSystems Explorer (NOT the default VS Code file explorer) to show the local copies of the documents? If not, the objectscript.explorer.alwaysShowServerCopy setting can be removed. EDIT: This setting will be retained for backwards compatibility.
  2. Do any users edit DFI files locally and have repositories that depend on the folder splitting behavior? If not, that special handling will be removed and DFIs will be treated like any other Abstract Document type. EDIT: This behavior will be retained for backwards compatibility, but newly exported DFI files will not be split into subfolders.
  3. Should the automatic deletion of files on the server when the local copy is deleted be guarded by a setting so users can disable it? EDIT: This is covered by the new objectscript.syncLocalChanges setting.
  4. This extension has a feature that will attempt to adjust the name of a class or routine when it's copied or moved to a new location within the workspace folder. This was implemented to help developers keep the file path and document name in sync. It can be turned off using the objectscript.autoAdjustName setting. Do users value this feature? Should the objectscript.autoAdjustName setting be set to false by default? Should this feature be removed entirely since the document index removes the need for the path to match the document name? EDIT: This setting's default has been changed to false.

Here's how you can share your feedback:

  1. Download the zip file at the end of this post and extract the vsix file contained within.
  2. Install the vsix file in VS Code using these directions, or by dragging the file from your file explorer into the Extensions view in VS Code.
  3. Follow your normal development workflow and try out some new features.
  4. Share your experience here, or on the GitHub pull request.

Thanks in advance for trying this out and we hope you like the changes!

vscode-objectscript-2.12.11-dev.1401.vsix.zip

Discussion (20)8
Log in or sign up to continue
Hendrik Schaefer · Sep 26

Hi Brett, 
thanks for providing these changes, we are looking forward to using Git, but we have seen two issues.

git switch/checkout between branches
New and deleted classes are uploaded to iris server or deleted. 
Changes to existing files are not recognised. We expected that the modified files should also be imported into the iris instance.

Export for client side
When you export from the Iris, it immediately uploads it to the server again.

0 0
Evgeny Shvarov · Sep 26

I use VSCode client-side coding with IRIS every day. Caveats:

1. it'd be great to ease connection to a dockerised IRIS - especially if docker-compose file is not in the root. Anyway the settings.json is a mandatory component, though it can be just the same all the time.

2. Saving changes for UI elements to changed local files for some components of Interoperability and IRIS BI is not complete. For example, editing pivots in the analyzer, term lists, lookup files, etc.

3. git-source control becomes a must-have for client side editing - especially for UI elements. Maybe we could consider some functionality a mandatory part of ObjectScript extension?

2 0
Brett Saviano · Sep 30

1. Connecting to any server is pretty easy so I'm not sure why we'd need to add a special case for dockerized IRIS.

2. Can you elaborate please? Are you referring to the lack of BPL/DTL UI integration?

3. This is incorrect. git-source-control is a server-side source control solution. You must use server-side editing to work with it. We do not and will not support the use of server-side source control classes with local files.

0 0
Evgeny Shvarov · Oct 1

1. Yes, but it can add some automation, as for docker-way port can be a random everytime, so this mean manual setup every build. Which is easy to setup, but every time.

2. Yes, UI Integration. And, if we are talking about client-side editing it is possible to edit those files manually (they are just XML files) of course. But ideally, the developer could call a UI in IRIS to edit the file from within a file, and the changes be saved into this file after editing in the IRIS UI app.

3. What exactly is "incorrect"? ) git-source-control perfectly works as a tool to deliver changes made in IRIS developer UI tools into client-side files. Well, you can say that it is server-side editing, and I agree, as every IRIS-driven developer UI tool is on the IRIS side, meaning server-side in this case. But still, it works perfectly and doesn't demand developers to change their client-side approach to a server-side in this case.

0 0
Evgeny Shvarov · Oct 1

Hi @John Murray !

Yes, it just works, thanks to @Timothy Leavitt and his team.

The only thing you need is to make sure that your dev module is described via IPM, and install and setup git-source-control.

Here is an example template for interoperability production that demonstrates the feature. 

And here is the only setup line that is needed after git-source-control is installed via IPM:
 

 zpm "install git-source-control"
    do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")
1 0
Brett Saviano · Oct 1

Integration with the BPL and DTL will be available when the new versions of those editors are released. The VS Code integration will support client-side editing as well. The Rule Editor integration already does so.

You're mixing up what we mean by "client-side editing" and what git-source-control does to maintain files in Git. In VS Code, client-side editing means "editing files on my locla file system directly". git-source-control is used when you're editing files directly on an IRIS server, and it handles the projection to the file system so Git can pick up changes. These are fundamentally different development models that shouldn't be mixed. Mixing them can lead to files being out of sync and changes being lost or overwritten.

0 0
Evgeny Shvarov · Oct 1

@Brett Saviano , maybe I'm mixing something up, but I'm just trying to provide you feedback, that developers that follow the client-side paradigm (actually the majority of existing developers to my knowledge) should still have any option to edit BPL/DTL and DFI and today the way is via server-side UI tools, and of course, they would expect changes reflected in their client git setup, which git-source-control wonderfully does.

0 0
Timothy Leavitt · Oct 1

The purpose of IRIS embedded source control features is to keep code changes made in the database synchronized with the server filesystem, to automate any source control provider-specific operations in a way that ensures that synchronization, and to provide concurrency controls for developers working in a shared environment (when relevant). In the days of Studio, all code changes were made in the database first, rather than on any filesystem, so you needed an embedded source control solution to get real source control at all. With client-side editing in VSCode, there are *still* some changes to code that are made "in the database first" - specifically, all the management portal-based graphical editors for interoperability and business intelligence. For such use cases, embedded source control is relevant even when you're developing against a local Docker container (which I'd consider modern best practice and prefer over a remote/shared environment where feasible) - otherwise, you need to jump through extra hoops to get your changes onto the client/server filesystem.

In a client-centric mode, it's totally fine to use git-source-control alongside the git command line, built-in VSCode tools, or your preferred Git GUI (GitHub Desktop, GitKraken, etc). However, this misses an important benefit of git-source-control: when you pull, checkout, etc., if you do it through the extension, we can automatically reflect the operation in IRIS by loading added/modified items and deleting items that have been removed in the database. If you make changes on the filesystem through one of these other channels, it's up to you to make sure things are reflected properly in IRIS.

Another benefit of git-source-control for local development is that when working across multiple IPM packages loaded from separate local repos, changes made via isfs folders will automatically be reflected in the correct repository. This is more natural for established ObjectScript developers especially (e.g.: "I just want to edit this class, then this other class in a different package") than a client-centric multi-root VSCode workspace, which could achieve the same thing but with a bit more overhead.

2 0
Colin Brough · Sep 27

Auto-adjust / design question 4: we'd find this useful, especially if it handles bulk renames - a bunch of classes implementing a data type, all being moved in one go from one place in the class hierarchy to another and all being consistently renamed.

So files X/Y/A.cls, X/Y/B.cls, X/Y/C.cls, and containing classes X.Y.A, X.Y.B, and X.Y.C being moved to Q/P/A.cls and Q.P.A etc. Especially if Properties defined in X.Y.A as "Property pp As X.Y.B" becomes "Property pp As Q.P.B" when renamed.

0 0
Joel Payeur · Oct 22

@Brett Saviano 

Hi,

answers to your design questions:

  1. I'm good with the VS Code explorer. The only issue I encounter is that sometimes either due to desync of some sort or because of file/class renames, my local does not match up to what is on the server. The InterSystems Explorer does show that files are on sever but not on disk, but it does not seem 100% consistent.
  2. We don't use DFI
  3. For me no, I'd rather like the sever to always match what is on disk, including deletons and renames
  4. Anything that keeps the server up-to-date with my local changes is welcome and should be enabled by default IMHO

Might be off-topic but I'd love it if I could use a client-side code formatter such as Prettier. To my knowledge the server formats the code and we have little to no control over that.

Also in the realm of off-topic stuff, we like to use "objectscriptQuality for VSCode" for ObjectScript linting and I have wondered if this isn't something that should be handled by the InterSystems team. From my own digging this extension uses a branch of SonarLint that it bundles along with the ObjectScript lint rules, haven't had any problems with it but I thought I'd raise it up with you guys for a professional opinion. I don't like the idea of having two versions of Sonarlint runnig in parallel (one for ObjectScript and the latest for our other languages). Maybe i'm just off my rocking chair though.

Joel

0 0
Brett Saviano · Oct 22

Hi Joel, thanks for the feedback! There's no reason why you couldn't have Prettier format your local files. It just won't work as well as it does for other languages because there's isn't an ObjectScript plugin (AFAIK), and some elements of class definitions (everything that isn't implementation code) is re-rendered after syncing with the server. I have looked at the "objectscriptQuality" rules before to see if there's anything that I should add to the Language Server extension and I came to the conclusion that it wasn't doing anything that was really valuable. If there are specific rules that you find useful I'd be happy to hear your thoughts, but I've resisted adding a bunch of Diagnostics/formatting options for "code style" issues  because many ObjectScript developers don't agree on them!

0 0