· Oct 26, 2016

Source Control dialog box in Cache Studio - pre-Atelier! Cache 2016.1 version and below. Authenticate developer before commit...


I'm working on a project that integrates the Subversion source control tool with Intersystems Cache Studio. I realize that Atelier has come out with 2016.2 developer edition which has built-in support for source-control, but it needs Cache version 2016.2. We don't work on that as yet. My question is simple. I've built a menu, interfaced with Subversion, validated my globals, and built a fully functioning source control system. However, I need to authenticate the user before every commit to the master repository. I want a dialog box which prompts for a password every time the user tries to commit. The dialog box mechanism has me stumped, because I don't see any standard way in Cache ObjectScript to handle it. With a CSP and a Zen page, a dialog box is simple, but I do not know how to make a standard dialog box open in Cache Studio without any web applications. Just a plain-vanilla windows dialog box would be nice. Is there any way to do this? Has anybody worked with a similar issue? Could anybody who has already done this share their knowledge? Please? Thanks in advance.

Discussion (5)0
Log in or sign up to continue

Assuming you're doing this using the Studio extension framework, the class reference for %Studio.Extension.Base has really helpful documentation.

I think the pattern you want is:

In UserAction, return Action = 7 for your menu item(s):

7 - Display a dialog with a textbox and Yes/No/Cancel buttons. The text for this dialog is provided by the 'Target' return argument. The initial text for the textbox is provided by the 'Msg' return argument

The user can enter a password in this dialog. Then, in AfterUserAction, you can handle the user's response.

In a development process, you can use any latest version of Caché, and export all code to source control system, in version which you use in production. It is not so difficult as may looks. Except only if you use so old system, like 2010.1 or earlier, because export qualificator /cacheversion supports version 2010.2 and later. In this case, you should have some building process, which will be at right version, which you need. I've used this way for years, and for our client we built two versions 2010.2 and 2012.2 from the same repository. You just should not use some new features, or use macroconditions by version, except JSON, you can't use anyway if lowest version doesn't support it yet.