· Jun 18, 2018

Project structure in Atelier


I am planning to develop a new ensemble project with REST service, requests, response, business service, process and operations in Atelier. Is there any specific folder/package structure  which i can follow? Appreciate any suggestions.

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

Thanks for this question, I think it's one that a lot of Atelier users will have. In general we recommend storing each of the different projects that you are working on, or closely related pieces of those projects depending on their size, in their own Caché packages. That helps when you are using source control, as you can pull down just one or a few packages from source to work on in Atelier, rather than having to pull in an entire source code repository.

The main considerations with Atelier will be:

  1. You do not want to have too many files in a given Atelier Project, as this can cause performance problems. (Unfortunately I cannot put a number on this, since it really depends on the size and complexity of those files.) An Atelier Project can be thought of as containing a unit of work - maybe it's the set of files you need to edit to implement a particular new feature.
  2. To help with the potential performance problems I mentioned in #1, working sets will be your friend. This is an Eclipse concept - a working set groups together elements and allows you to restrict the resources that you are viewing. In turn that will limit the background processing done on files/projects not in an active working set. This is discussed in the Eclipse documentation here. There is also some information about that in the Atelier-specific docs here.

We'd love it if you could post more about your experiences, since this is something that effects many users. You can note that in a comment here, or preferably write up a new article and post it on the Developer Community as an example for other users!

Hi, Shameer!

As @Nicole Aaron mentioned, there is no officially proposed folder structure for your  InterSystems project, but I can share one typical approach.

The upper folder is basically named "src" assuming source code inside.

Files inside "src" could be splitted by source type. E.g.:

"cls" -  for ObjectScript classes,

"inc" -  for include files,

"mac" - for mac routines,

"dfi" - for DeepSee dashboards and pivots.

Every class name consists of package(s) and class itself. So class package could be projected to a folder. E.g. source code for the class Sample.Person will be stored in the file with following path:


There are numerous projects on Github which use similar approach. You can find examples of such projects via these cacheobjectscript-udl tag, e.g. this project.