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 :)

Terrific.. thank you for confirming Herman.

And isn't that slick? :)

Just go to "About Atelier"

There is a splash screen and it should show something like:

Version: 1.0.112

Which is build 112 of Atelier. We switched to this scheme about a month ago John.

It should work automatically with recent clients. I am uncertain what build you were trying to update from but as of mid february we should be prepopulating the URL for you

We continue to update both the client kits there and also the cloud server instance that supports it. Once you have Atelier installed you can upgrade it any time through the "Check for Updates" facility that is built in and get the latest kit. I upgraded my instance this way today!

I will have the text corrected as soon as possible

FYI - there are some changes coming here in 16.2

I posted a compatibility blog statement that has not been approved yet but there are a few changes coming in this area.

Great info Ben - thank you for sharing!

Generally we favor ANTLR. The COS parser required complexity we were not confident we could achieve with ANTLR. Having said that we continue to debate this internally as Jonathan expressed. When we release Atelier we do anticipate publishing a lot of the code to open source. Dmitri I will reach out to you through the Russian office as we may be able to leverage your knowledge.

We are still deep in a development phase. Robert Nagle does want to open source Atelier development at some point further along in the process. Its not yet clear exactly how we will do that but keep an eye here for an update.

I strongly recommend people to each have their own system and to sync to a source control system as a preferred methodology. The one use case I have heard to justify putting a lot of developers on one box is where you are doing something like Ensemble and you have a complicated integration environment, perhaps with security restrictions that make it prohibitively difficult to replicate that set up across multiple systems. But even tasks like this become easier with tools like Vagrant that "package" an application and install it with standard customizations across multiple systems and even OSes.

Having a bunch of developers touching code in the same namespace is a perilous thing. How do you know what is production code versus something I was noodling on as an experiment this morning? Fighting over the same classes? These are all nasty repercussions of having a bunch of people editing on the same system.

There are means to load the UDL format of Atelier on the server as well.

There are ways around this. You can export code back from Atelier in XML format and not use source in Atelier. Its not recommended but it does work.