Work with CSP / JavaScript / CSS etc files on the client side?

[ChrisJMarais]

We need to be able to work client-side with CSP /JavaScript /CSS etc files.

Currently, we can only do this with "Server Side Editing" enabled and this is not optimal.

In eclipse when using Atelier and you open the "Server Explorer" and browse to your Server -> Namespace, you get options for Classes, Routines, and CSP files. We need the same functionality provided by Atelier in eclipse in this extension.

[daimor]

Could you explain a bit more? At the moment you are able to edit your CSP files locally, but these files, will not go the server and stays only locally, and supposed to be mapped somehow directly to the place where they used.

Looks like you need the way when some of your local folders considered as CSP folder and related to a particular CSP application on the server. And you would like to have an option to explore the content of any CSP application on the server, with ability to export them. Is it correct, any other suggestions?

[ChrisJMarais]

@daimor Yes you understand the request correctly, In short we need files to be handled int the same way classes are handled, like in eclipse with Atelier.

[vsfan]

I up-voted the question mainly because I think CSP support will be very welcome to people like me who still uses CSP to certain degree. I think ISC needs to make the stand more clear that whether they have the intention to support/enhance CSP in the long run, which I think the answer is more or less NO atm. The recommendation I am hearing has been using any client framework and works with Cache/IRIS as the back end providing data / web service / table.

[gjsjohnmurray]

Related to this, #235 drops the broken "Export" option from the ObjectScript Explorer context menus of the "CSP Files" subtree. It can be reinstated if/when implemented.

[mcronin117]

I would also like this functionality so we could have all the benefits of regular client side source control with our CSP heavy application. I'm trying to avoid the server side source control hooks if possible

[amirsamary]

I also miss this feature. The other day, I wanted to write a IRIS Workflow Form Template using CSP and I had to keep copying the CSP file to the server manually in order to get it there. Many customers still use CSP and they may just continue using the old Studio just because VSCode won't do it.

[gjsjohnmurray]

@amirsamary you can already work with CSP files as long as you are willing to edit server-side (aka 'isfs mode'), which is exactly how those who continue to use Studio are already working.

[amirsamary]

Thank you.

But I am working using VSCode in the normal way, with my source code in GitHub in my local folder.

I am developing on Kubernetes (k3d) so server side source control is no good... If VSCode is saving the source directly in the server without saving it in my local folder, how can I build my docker images and push them to my local docker registry to be deployed in Kubernetes? Would I have to push the source from the pod to Git, then pull it back into my local machine so I could rebuild a new image? It is just unnatural and cumbersome... So this is a huge benefit (1).

Then, when the image is deployed in Kubernetes and running, I want to continue developing, testing and debugging and the fact that VSCode can continue saving the source in my local filesystem while synchronizing with IRIS running in the Pod is just fantastic and convenient. I can use normal git tools like git diff and git stash (benefit 2). I could use VSCode git plugging (I prefer the command line - benefit 3). I could use normal VSCode tools to search, replace, etc. Or command line tools like find, grep and sed. Just normal stuff... (benefit 3)

It is very common to jump to a branch to peer review some code and rebuild the images with the source of that branch and deploy the images in Kubernetes to test. How would you do that with server side editing? Deploy an empty IRIS pod, tell it to download the source code from git in the server, compile it and then test? Too complicated and unnatural for anyone familiar with docker. You want to build an image, deploy it as a container and test it. (benefit 4).

So when I am done with my peer review, I can just go back to my branch, rebuild the images, redeploy and I can simply continue with my work. It just takes a couple of minutes. Seriously. Simple and elegant.

I understand our customers will want server side editing because they have been working like this for so long... But this is not the way of the future. Actually, with VSCode the way it is, and if I am a heavy weight CSP developer using docker-compose, I can share a volume and get it done. With Kubernetes I could use skaffold (I use it for Angular) and get it done as well. But it should not be necessary to do these tricks. VSCode is doing an amazing job with classes and routines. Why not allow us to do the same with CSP pages and other types of documents such as Dashboards, Pivots, Lookups, etc.?

Respectfully,
AS

[gjsjohnmurray]

@amirsamary I understand all that. I was responding to your statement that CSP customers might continue using the old Studio because of this. But if they remain with Studio they are working server-side, so they can actually move to VS Code and continue to work server-side.

[amirsamary]

Good point. :)