Phil - I wasn't suggesting that you use the Ens.Deployment.Utils but rather the Studio.Project utilities.  This will allow you to put in any specific classes that you wish to include (including the Production definition which should include all the pointers to the new BOs, BPs, and BSs) so that you can cherry pick what goes into your next environment.  I am not familiar with the Ens.Deployment.Utils so I can't compare the approproaches

There are different kernels but other than that you should be able to run the same ObjectScript code on both platforms and it will behalf identically.  If you are going to be doing file interactions, then I suggest using the %File library class which will make your code portable between Windows and UNIX file systems.  Likewise if you are calling out to other executables, you will need to instrument your code to call out appropriately based on your platform. 

I am assuming you want to create a tag-based CSP page as a quick and dirty way to through up some data in a table?  If so, the basic steps would be:

  1. Load a JS library like https://www.tablefilter.com/ to make your filtering easy
  2. Write out your <table> and <th> tags 
  3. Create a <script language='cache' runat='server'> block to hold your ObjectScript which will fetch your result set 
  4. Use %SQL.Statement to create and run the query and fetch the data
  5. Iterate over the resultset, and write out a row of HTML for each row in the resultset using &html<>
  6. End your </script> tag and then end your </table> tag

Hope that gets you rolling!

This is definitely possible, although it will be very painful :)  You can use Studio to edit any sort of flat files on the OS, and Studio has been used for years to edit .js and .css files.  You can use Studio to edit the source files for your React or Angular app, but you will then need to use the CLI in order to build your app for testing (you could also roll your own server side source control hooks to do this).  So if your organization is currently locked into Studio, this can be done but you'll need to do extra work to make it work.

If you have the flexibility, I would strongly recommend that you leverage VSCode rather than Studio for this.

@Rich Taylor - John is correct, server-side source control models are fully supported and that is the dominant model for many (including internal apps at ISC, and our implementations in the field).  I did a presentation at Virtual Summit on how to choose between Private / Shared Dev servers and Client-side vs Server-side source control and what the IDE options are for each.  Tim Leavitt also did a session on the topic of server-side source control with VSCode.  Here are the links:

https://learning.intersystems.com/course/view.php?id=1638

https://learning.intersystems.com/course/view.php?id=1615

My team has been very active in the VS Code plug-in testing and development to ensure that it will be fully functional for our serverside source control based workflows.

Sorry @Jeffrey England - I only just saw this now (feel free to use an @ mention in the future).

This control doesn't currently include any sort of dropdown.  It was based on the System lookup in the old UI where people could just drop in their SysCode to drive navigation.  Adding a dropdown of some sort is on the roadmap, but it's not trivial as some people have access to hundreds of Systems (so it's not a simple dropdown - it will eventually be a combination typeahead dropdown which pulls from all Orgs a user has access to).  

We will be moving live an update to this component soon which makes it more clear that SystemCode is optional (but it will still be a text field).

Hope that helps explain things!

Ben