Announcement
· Aug 20, 2021

Video: Visual Studio Code for ObjectScript: Server-Side Source Control

Hi Community,

Enjoy watching the new video on InterSystems Developers YouTube:

⏯ Visual Studio Code for ObjectScript: Server-Side Source Control

https://www.youtube.com/embed/yuP8_NLvNl4
[This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]

Review configuration and the behavior of server-side source control extensions in Studio and see how these features map to VS Code. Developers already using server-side source control in Studio can adopt VSCode alongside their existing source control processes and repository structure.

⬇️ VSCode-ObjectScript on Open Exchange app gallery

🗣 Presenter: @Timothy Leavitt, Development Manager, InterSystems

Enjoy and stay tuned!

Discussion (7)3
Log in or sign up to continue

@Timothy Leavitt 
Does ISC have any plans to expand upon the server hooks further/modernize them a bit?

Using a detached model of source control (i.e., non-isfs mode of VS Code w/ ObjectScript) for our org that revolves around traditional hospital/health-org Ensemble usage doesn't really work well, in particular with our analysts that aren't developers in any sense but still make table updates and other minor tweaks here and there within the Management Portal that fall to the source control hooks to handle.

In particular, in the UserAction space, there isn't a clean way to launch a small modal window for providing a UI to manage a user's source control settings - as the source control hooks effectively assume whatever CSP you're launching from UserAction is going to show a document that needs to be 'controlled' by wrapping it in an iframe managed by %CSP.Portal.SourceControl.Dialog.Manager or similar.

I have figured out ways around this but it's kind of clunky. So hopeful may we could launch our own Angular page from UserAction so we can control the dialog size, UI, etc. (and maybe there already is an undocumented way I just haven't dug further enough to find yet.)

In the scenario I'm referencing, the use would be inside Management Portal as our analysts do not and will likely never utilize a VS Code or even Studio IDE. They manage integration lookup tables within the Interoperability (formerly Ensemble) space and maybe a few other small items therein but therefore we must rely on the source control hooks to a degree to ensure we can capture their changes as well.

I agree, however, in principle and for our developers have another way to manage the 'backend' settings generally stored in globals with a nicer frontend. But nice to have a one-stop-shop whenever possible from a user-friendly standpoint (i.e., if it could be launched from a Source Control menu on the Production page within the Management Portal without being caught inside the iframe Dialog.Manager)

@Craig.Regester I'd be really interested to see what you're doing with the server hooks. (Maybe @Raj Singh would be interested too?) It sounds like you're rolling your own; what are you integrating with? Git, Perforce, SVN, etc.?

A few tidbits that may or may not be relevant for your use cases:

%Studio.Extension.Base:UserAction (see https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic....) with Action=3 will also launch an external browser given a full URL provided in Target (not necessarily CSP, but could be). This isn't truly a "modal" window but would give you a little bit more control perhaps.

For the sake of VSCode specifically there's a different API (not really documented) for closing a page opened with Action = 2 - specifically, sending a message to the parent frame (a VSCode web view) with data {"result":"done"}. This looks something like (in %CSP.Page:OnPage):

    If (%request.Get("EndTemplate") = 1) {
        If (%request.UserAgent [ " Code/") {
            // For VSCode only:
            Set %response.ContentType="text/html",%response.CharSet="UTF-8"
            Write "<html>",!
            Write "<script type=""text/javascript"">",!
            &js<if (window.parent) {
                window.parent.postMessage({"result":"done"},'*')
            }>
            Write "</script>",!
            Write "</html>",!
        } Else {
            Set %response.ContentType="text/xml",%response.CharSet="UTF-8"
            Set delim = ##class(%CSP.StudioTemplateError).#DELIM
            Write "<?xml version=""1.0""?>",!
            Write "<template><![CDATA[BODY",delim
            Write delim,"]]]]><![CDATA[></template>",!
        }
        Quit $$$OK
    }

Appreciate the detailed response Timothy - I'd be happy to show you what I've been working on. Still a bit of a work-in-progress but I do actually have it in a functional state - just some small nuggets for our non-developers I need to button-up.

Yes, very much 'rolling my own' but I learned substantial amounts from existing OEX solutions of course - refactored, cleaned up a lot of functionality that didn't fit with our desired workflows, and integrated my GitHub Enterprise private org App I created so the server can act on behalf of the user after the user authorizes it via OAuth2.

Git is used on the server simply as the transport mechanism for the 'server' to talk to GitHub as the App but possibly removing that crutch as well long term.

Ben is correct that the window launch would be from SMP and that's where I've struggled a bit. The hooks are a lot friendlier within VS Code or Studio but the SMP side leaves me wanting - not just for these modal windows but also the general dynamic-ness of the menus.

e.g., early on I toyed with the idea of some 'short-lived branches' for our developers and having a menu DisplayName updated to show their current branch. This worked beautiful in VS Code/Studio but SMP just ignored any updates to the DisplayName essentially. The lack of consistency was frustrating so I just dropped that functionality for now.