I make every effort to take a passive role here on the community but I have to make a statement here. What you are saying is that regardless you are leaving people with a broken experience. If Atelier does not get the added editors needed to support HealthShare development fully with integrated source then its appeal is greatly diminished as you have large pieces of work that miss out on integrated source control. But you can't go back to Studio either as it leaves you with no supported plugins for ANY source control system at all and means you have to make that implementation yourself via Studio Hooks. Neither of these situations is viable unless your intent is to leave people with no forward path for managing code and developing on ISC technology using any modern professional development approach.

Hi Dmitry,

As I mentioned we are still working to complete all functions in the COS parser. I will make certain the developers are aware of this syntax error.

Shhhhhhhhhhh... just a few minutes more.....

You can jump from code you are looking at to referenced calls via the Ctrl-F3 shortcut. Studio's "GoTo" feature which allows navigation to a specific line+tag will be included in the 1.1 release.

Herman - there is a place to report issues. Its the same as anything else with our product. The WRC is fully supporting Atelier and issues are tracked in the same manner as any other part of the product. We are encouraging general conversation here because it is of benefit to everyone and not specific to Atelier as a policy point.

As for choosing Eclipse. It boils down to ecosystem. The editors you mention are all nice but none of them support the entire range of features we can get from Eclipse. You will note that by adopting a REST api we left it open for ourselves or anyone else to expand the functionality of any popular IDE on the market for use with our products.

I did this as well but set it up with https which I found to be much simpler to do.

We looked at and abandoned that approach in the early days because it is not flexible enough. You get only a single projection for a given class and any changes to it require a recompile of the class. Compose() is an attempt to move past those obstacles.

We will be updating the keys shortly

Please read the announcement here:

https://community.intersystems.com/post/announcement-about-cach%C3%A9-2…

We have been holding updates of Atelier to finish refactoring to conform to the changes outlined there. Kits are being published for 16.2 today and a new Atelier kit will be available in "Check for Updates" today or tomorrow.

There are multiple steps required here.

1) The two csp applications that support the Zen app and the REST app must both be defined to store their license information ( cookie ) in the same location on the browser.  You will need to make sure you have enabled cookies for sessions and that both apps put the cookie in the same location.

2) In the CSP Rest page you must tell the csp server logic that you want to use sessions. To do this you need to ovverride the parameter "UseSessions" and set this to true. This will persist the session from call to call and will look for and update the session cookie in the http request.

So you might do something like:

/csp/mynamespace as the URL for the zen app and then have /csp/mynamespace/REST for the rest calls..

Both would store the session cookie at /csp/mynamespace

This should get the same license and user allocated to both applications.

Just in case you are asking about why Cache has .mac files and .int files. These are shorthand for macro and intermediate. Both are routine files but have different roles at compile time.

A mac file can contain macro code like $$$InsertCodeHere. When this routine is compiled in to intermediate code the macro has been evaluated and replaced with actual runnable objectscript code like

write !,"Bill was here"

You can only use macros in .mac routines.  Classes support macros because they get compiled in to .mac's and then generate INT code

Dmitry is correct - this is simply a feature of Atelier.

ClassMethod getPerson(
ByRef pParms,
Output pObject As %RegisteredObject
) As %Status

This is perfectly legal and works just fine.

We are working to get the latest node into the distributions. Its problematic because it requires newer versions of compilers then we are currently using. Once the compilers are upgraded the new node will ship in the distributions. In the mean time we are making them available separately thru the WRC

Its not a select so you are going to have trouble firing the event programmatically. What are you trying to accomplish from a functional point of view?

There are lots of ways to do this:

1) Expose as stored procedure and call via the SQL gateway interface...

2) Wrap in a web service and return the results that way

3) ZN

4) Use extended syntax

5) Map the class / table / routine

Just to clarify for people. We are not working to enhance DOCBOOK searching. You can use Google search today.. right now.. on our current documentation set via the community. This is an attempt to modernize the layout and look of what DOCBOOK presents once you have clicked a search result and displayed what you get.

Just as an FYI - Find In Files in Studio is painfully slow. You will find that moving resources in to Atelier will deliver results with much better speed and options for searching. We will be adding a feature as noted to search the server from Atelier but in general I find a client search way more effective.

Wow. Just wanted to say a great topic guys! Thank you

There has been no change in the status of Weblink in 4-5 years. It continues to be available as a separate download for supported customers. It is no longer shipped in the product but that has been the case for a long time. If you have a working Weblink application you can rest assured it will continue to work for as long as COS is a valid language for our technology

In general I am of the opinion people should use the right tools for the right job. There are IDEs that are for producing code. There are source control systems for maintaining code and its history. There are tools for doing deployment. They are not all the same tool. I just spent a few days visiting a site that has the ability to do push button deployments of complete installs or patches to public or private clouds. That is how people should be looking at this issue. Its the realm of DevOps, and Cloud and enterprise management systems. Not the IDE itself. We can do this with Atelier. I can pull a project from source into an Atelier project and then push / sync it to a given Cache instance. But this is not the optimal way to distribute code.

I encourage you to take a look at a tool like Chef as one example of a more modern way of deploying code. There are many many many more options out there but it is not my expectation that Atelier is ever going to be my preferred method for distributing code from source to production.

1) Deprecated for COS means we simply do not want to encourage people to use these APIs anymore. There is no requirement to merge other then hopefully the benefits in the new code that led to the deprecation in the first place.

2) Atelier has the ability to display any deprecated syntax visually and also link to its documentation, which should have some indication of why it was deprecated and what replaced it.

3) Atelier will also have full refactoring capabilities for updating deprecated syntaxes though that will not cover data migration issues as outlined in this particular case.

4) We also intend to have full support for code analysis in Atelier which can be run and show me anywhere I am using deprecated syntax and suggest solutions.

We are still working on CSP support. It is very close to completion

Shhhhhh John.. those are secrets :)

Yes this is creeping in though we know we have a few problems.

Don't give away my other secret.

Hi John..

You asked an interesting question here and then you laid out a structure that while perfectly logical broke my heart at the same time. Doing development on the oldest version is a pattern I have seen many times in the wild. But it leads people to a dead end. You can't always be 3-5 years behind the technology curve in your application. That way leads to product failure. You have to have a development process that lets you keep up with new features and key industry trends. If that requirement leads to pain in QD and means you are having to push your base to upgrade that is the process of modernization and relevancy. Fortunately most issues with pushing classes back show themselves at load / compile time as opposed to run time, SQL excepted. I spoke to some people in Ben Spead's team on this today and they try to do the opposite. They try to keep development on the current release and to verify with QD that the code loads, compiles and runs properly on older versions thru automation testing and such.

Thank you Nikki - this is a bug. It should check the project first and only go to the server if it cannot find the class locally in the project.

We are working on some infrastructure that will allow existing add-ins and templates to be called from Atelier. I just saw a demo today. Just keep updating :)