· Dec 7, 2015 4m read

Source Control Hooks and Atelier

So another topic that has been of interest to a number of people since the beta was put up last week is in regard to Studio Hooks and Atelier. This requires a bit of background and then some discussion of how the architecture of Atelier necessitates some changes and then what our current thinking on the subject is.

Studio hooks were added to Cache over 10 years ago. They have two primary usages. The first is that on an appropriate action such as creating a new document, or compiling a document a callback is executed whose job is to interact with external source control systems. This is done by writing COS scripts that “do the right thing” for a given source control system based on the callback invoked. All of this code ran on the server and used all the facilities available on the server such as locks and transactions etc.

All ISC provided for this was the presence of the callbacks. We did not implement, recommend or support any specific source control system. Over the years a few things changed in this area. Because we were a Perforce shop ourselves a perforce sample of what a Source Control implementation would look like was added to Samples as guidance on how a customer could roll their own. And over time SEs contributed two other kits due to their popularity in the field - Subversion and Team Foundation from MS.

This lack of a proper integration with Source Control has been one of the major deficiencies of Studio and a source of constant pain and frustration for customers in the field for the last 5-8 years. Telling customers they had to roll their own source hooks was met with derision.

However a second use case for Source Control Hooks came to light over this time as well. This was the idea that because we were giving you a callback at the point of compiling code that people had a handy point for implementing coding “rules”. You could evaluate the code and reject it if it doe not meet code quality constraints. You could even do “find and replace” work at the point of saving and compiling. We have a surprisingly large number of customers who are using Studio Hooks in this manner.

One of the major impetuses for moving to Eclipse was changing the Source Control story. We needed to give people a working out of the box solution that did not require customers to write a line of code to get their source to and from the source control systems that the market is using today. Eclipse has built in support for Git and has 27 freely available plugins for 27 different source control systems including all of the major platforms that our customers have inquired to us about in the past.

Of course this is not a straightforward issue. Eclipse does all its source control interactions on the client. We can support this easily out of the box and we do. The problem is what can we do for customers that invested in Studio Hooks. Atelier has no notion of locking. It uses the server merely as a compiler. In fact it is REST based and decoupled entirely from the server except at compile time or when debugging. We also do not have the ability to let users add UI to Atelier that is integrated with the server as we could in Studio. All source integration in Atelier happens through the “Team” framework on the client. So let’s talk about what we did do, and what might be possible down the road.

First and most importantly we do support Studio Hooks. If you are running Atelier against a namespace where Studio Hooks have been activated it will do the right thing and your callbacks will be triggered at the appropriate times. However this behavior will be atomic as opposed to in Studio. If I open a class in an Atelier project, nothing will happen on the server as we have not connected to the server yet. When I go to compile that class though three actions will happen concurrently - an Open, a Compile/Save, and a Close all in the process of one operation. So the class or routine would get checked out, would get updated and would get committed back to source control, all within one call to the server. If your hooks included logic to “beautify” or validate code that would still happen as well. In this regard we “support” Studio Hooks. However there are no menus in Atelier for “adding” a document to source or adding other UI elements you may have bound to Studio Hooks in Cache Studio. We have not and will not be implementing those elements at this time.

Why you might ask? Because to interact in that manner in Atelier would mean that essentially we have to write a complete Team Framework plugin for Eclipse ourselves that was a plugin for the Studio Hooks Source Control system. Except of course there is no Studio Hooks Source Control system. All it does is move the job back to the server, where we leave the actual task of implementing source control….. right back in the lap of our customers where we already agreed it never belonged. Essentially we have to invest resources that could be used to make the Atelier experience and the development experience with Cache better in building a plugin whose only purpose is to get you back in to the dead end from which we are trying to liberate you.

Needless to say we don’t like losing any feature or adding any compatibility issue to Cache. And we know a lot of people invested in Studio Hooks to even construct applications. This is simply to explain what the story is today as we go to beta with Atelier. I look forward to your comments and criticisms and perhaps even proposals for solutions that I may not have considered here. What I can tell you is to try a plug in for your source system of choice. I think like me you will find going back awfully hard to do once you have seen how seamlessly they integrate and enhance your experience with Eclipse. I have played with Git, Perforce and TFS and can vouch that all of them work perfectly with Atelier. Happy Coding!

Discussion (12)1
Log in or sign up to continue

I was hoping to see some workflow videos this week showing how InterSystems envisions the development process is to work in Atelier.

Our primary desire is very common amongst most platforms in the industry...

We want to easily deploy any branch of code to any Cache Server of choice (development/staging/production).

Given the demos and docs we have from InterSystems so far, this is not entirely clear.

I am still very confused about the Studio hooks too, I am not sure that they give us the ability to meet the desire above either.

We look forward to hearing more.

Bill, I have developed our own Cache based solution that is hooked into our build process too. To utilise Atelier in future versions without compromising the effort put into SC hooks, what would be useful is an example Eclipse/Atelier project as an add-in for launching web pages as custom menus. Such that they can be added to and emulate the existing capabilities offered in Studio of calling web pages from such menus that can utilise the concurrent license login of the operator connected to the cache DB. Additionally, the ability to trigger such actions based on existing capabilities at edit time to co-ordintate the current edit state on the server. I assume this would be an option exposed via the REST inrterface.

We could only move forward with Atelier in 2016+ with support for such hooks and only really need a guiding Eclipse add-in project with appropriate REST calls available as example to build our own add-in.

Without this, we would need to continue to work with Studio on PCs and Servers which i assume will be an option.

Trevor - I would need a lot more information to provide you with a complete answer. I will give you the 50000 foot answer and then we may need to dig a little deeper.


There are no REST apis for interacting with the Studio Hook mechanisms at this time. As I said in the article that is really working backward from what Eclipse gives you out of the box and more toward building a Studio Hooks plug in for Eclipse instead.


Studio is a powerful tool and one that can lead to very creative things if the people using it are willing to invest in the entire stack needed to effectively add functionality to Studio. This stack requires knowledge and capability of leveraging:








Add-ins / Templates


I know a large number of people have done this work. We are trying to create an IDE that follows a more modern and standard approach to adding functionality to an IDE. What that means with regard to Studio Hooks may evolve or change over time but we are starting from the baseline that what Eclipse offers out of the box is better.


Let's talk for a moment about your larger question of add-ins and launching web pages that share license info from within Atelier. We have this issue ourselves. Let me give you a real world example:


One of the most frequently used templates in Studio is the Soap Client Add-in interface. This is a CSP document that provides an interface that lets you point to a URL or a WSDL document locally, parse it, decide how the classes to be generated should be processed and then eventually launches the import. The actual work is handed over the server and done in a process there with the compilation output redirected to the Studio. This is a very complicated piece of code and one that causes confusion and issues for people related to https, validation to access a given document or URL etc. But functionally it aligns closely to what you are describing above. For us to port that wizard as is we need to launch a web page from Eclipse. Let it do its thing, not bleed licenses when it actually connects to the server and does its thing and then we need to tell Atelier about the classes that were generated when it completes. We have a working model for this in development with Atelier at the moment. I don't have the source to hand but I can drag it up given some free time. I hope that comes close to addressing your general case.


 We want to encourage people to build these sorts of tools in Atelier using the Eclipse stack and framework as opposed to studio templates and server side functions. We know that people have existing code and will want to port it over as easily as possible of course. More later.. Apologies it took so long but the holidays you know!

I just have found that $system.OBJ.Load() supports loading in an UDL format. And found $system.OBJ.ExportUDL() which can export classes and routines in UDL format. So, it means that we can easily organize work in Studio and in Atelier at the same time. What we should, it is to export all files in Studio hook at the same manner as it doing Atelier.

With this new possiblility, will be much easier to migrate from Studio to Atelier.