New post
AllAccepted answers
Ben Spead · Dec 19, 2019

Neerav,

For internal applications within InterSystems, we've chosen a webapp strategy of:

- REST services from Caché/InterSystems IRIS

- Angular8

- Angular Material

We are part-way into the implementation of this strategy and so far so good.  However, the work that we've done so far doesn't yet fit in the category of "tons of data to display' so I can't comment first-hand on the efficacy of this stack for that requirement (but you should be able to find experiences of others using Angular for data-heavy web apps).  We are using this for new application development, and we're also working to retrofit existing CSP/Zen apps and move them to this stack.  

Hope that helps!

Ben Spead · Nov 14, 2019

Mike - I think the issue is that Apache is working in conjunction with Web Applications defined in Caché, and it hands off requests to the Web Applications (e.g. /csp/samples), which then serve out the files (this is configurable btw for static files).  This is why you can put something in /csp/samples or another existing web application and it works.  The issue is that in putting something at \Cache\CSP\index.csp, there is no Web Application with a root of \Cache\CSP\, and so there is no Web Application to route the request to, and thus the 404 error.  You could create a new Web Application in Caché that points to \Cache\CSP\ but that would be a bit of a security issue because people could navigate to files in other web applications from there and potentially get to things they should not.

Why do you want to put something at the top level rather than in the root for a Web Application in Caché?

Ben Spead · Oct 28, 2019

Joel,

I completely agree with you!  

Within InterSystems we have at least one development team that has codified this via serverside source control hooks which automatically expand use standard case for all commands (there was a presentation on this at last year's Global Summit).  Adopting this tool is on my list of process/tools improvements for my development  team in internal apps.  There will be a discontinuity in the source control branches  when we turn this on and standardize everything in one check-in, but I think the benefits of having a standard way to representing commands without developers having to personally remember to do it the same way will be pretty considerable!

Ben Spead · Oct 18, 2019

David,

I suggest you look into using the DeployToFile() and InstallFromFile() methods of the %Studio.Project class.  A discussion of the topic can be found here in the docs:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ADEPLOY

Another option is calling  the following on individual classes:

 $system.OBJ.MakeClassDeployed()

But since you are looking at just pushing partial updates, most likely the DeployToFile() with the parameter to strip out the source will be your best bet.

Ben Spead · Oct 15, 2019

David,

Thanks for your feedback!

In general, Developer Download always makes available the latest GA version of our two Community Edition products.  In this case we wanted to be able to launch by Global Summit and so we went with the Preview since 2019.1.1 kits were not full GA yet.  There are ongoing discussions about the pros/cons of making containers available here rather than people just fetching them directly from Docker.  We'll let you know the final decision!

Ben Spead · Aug 9, 2019

I am assuming that when you are talking about 'folders' you mean the structure which individual items are exported into when you use your source control hooks, correct?  To achieve this you need to loop over all items in the namespace and call the source-control related export on each of them.

The way we do that for our internal systems is to the the BaselineExport() method in the %Studio.SourceControl.ISC class.  %Studio.SourceControl.ISC is our source control hooks class for Perforce, and I haven't tried calling BaselineExport() while another set of hooks are configured for the namespace, it may *just work*, especially if your GitLab hooks use the ^Sources global to describe the export structure.  Give is a try and let us know if it help (if not, I can get you the code for that method and you could adopt it for your purposes)

Ben Spead · Jul 5, 2019

could you please give a little more of a description as to what you are hoping to accomplish?  A JS file will be executed on the client, where-as "Caché Code" (by this I assume you mean Object Script?) is executed on the server.

You can edit JS files using Studio, you can create object script class projections to automatically create JS files with JS logic in it, you can send JS from a server process to the web browser, etc - there are may ways for Caché Code to interact with, inform or manipulate JS files.  We need more details for what you want to do.