@Ben Spead making a new itemset does work. I was not aware of the approach you are proposing, I guess I missed that, is this going to Source Control -> Refresh from Branch? 

@Ben Spead Thanks for taking a stab at it. 

Ok yes, good, it makes sense that is the default behavior.

I think really the only other pressing question is if this tutorial should run on Cache, not just IRIS.   I thought I had Docker installed on my machine, but I think I must be lacking an AD group or something to actually run it.

That said, Docker is new territory for me too: I just read the 'docker-compose up' command documentation and I'm a bit confused.  When you run a Docker image, isn't there a virtual machine at play?  How is Docker working in this context where I've unloaded the code from GitHub to my webapp and then running the docker-compose up command in that directory?  

Thanks for any help.

Mike

Hi, @Ben Spead, 

I'm using a plugin to change the color of each one of my workspaces. The plugin's easy to use and helps me a lot, avoiding mistakes editing in the wrong workspace.

Peacock
https://marketplace.visualstudio.com/items?itemName=johnpapa.vscode-peacock

The plugin creates the configuration inside the .vscode folder in a JSON file.

{
    "objectscript.conn.ns": "IRISMONITOR",
    "objectscript.conn.port": 52773,
    "objectscript.conn.active": true,
    "objectscript.format": {
        "commandCase": "word",
        "functionCase": "word"
    },
    "objectscript.export.addCategory": true,
    "workbench.colorCustomizations": {
        "activityBar.background": "#88d7ea",
        "activityBar.activeBorder": "#de41bf",
        "activityBar.foreground": "#15202b",
        "activityBar.inactiveForeground": "#15202b99",
        "activityBarBadge.background": "#de41bf",
        "activityBarBadge.foreground": "#e7e7e7",
        "titleBar.activeBackground": "#5dc9e2",
        "titleBar.inactiveBackground": "#5dc9e299",
        "titleBar.activeForeground": "#15202b",
        "titleBar.inactiveForeground": "#15202b99",
        "statusBar.background": "#5dc9e2",
        "statusBarItem.hoverBackground": "#32bbda",
        "statusBar.foreground": "#15202b",
        "activityBar.activeBackground": "#88d7ea",
        "statusBar.border": "#5dc9e2",
        "titleBar.border": "#5dc9e2"
    },
    "peacock.color": "#5dc9e2"
}

HTH

@Ben Spead That's great, got it now.

Is there a plan to change the actual Create CCR page to have a similar look/feel to the home page?

Amanda
 

Interesting questions.

  1. There are several ways to achieve clean and pseudo-clean builds:
    • Containers. Clean builds every time. Next articles in the series explore how containers can be used for CI/CD.
    • Hooks. Curently I implemented one-time and every-time hooks before and after build. They can be used to do deletion, configuration, etc.
    • Recreate. Add action to delete before build:
      • DBs
      • Namespaces
      • Roles
      • WebApps
      • Anything else you created
  2. I agree with @Ben Spead here. System default settings are the way to go. If you're working outside of  Ensemble architecture, you can create a small settings class which gets the data from global/table and use that. Example.

@Ben Spead @Evgeny Shvarov 

I watched the video, thank you!

As a new Cache developer, I'm curious to know if TestCoverage will ever be implemented in a future release of ObjectScript in the %UnitTest framwork versus why it stands alone as in InterSystems developed OpenExchange project.

Still learning the differences between Cache, ObjectScript, all the InterSystems' applications and how it all intersects with what my company has been doing in Mumps for the past 30 years.  

If I can reel back to some basics, however.  Because I never really written a complex applications, my sense of testing as always been "write a little, run it, write a little run it," and usually that was in Java.  It was easy to write a driver class or main method to test the code and see what was going on.  I suppose in a more complex system that is always growing, you need something like this unit test framework to single out these classes to run without writing a separate driver class, or at least in this case TestManager is acting as that driver class.  Am I on the write track on how to think about this?

Thanks for everyone's help!

(Originally posted by @Ben Spead on June 25, 2014)

This code snippet generates a list of Ensemble Lookup Tables and Schema documents in the user's current namespace. Run the code by running the class method "test":


Class benspead.EnsTablesSchema
{
    classmethod test() {
        If ##class(%Dictionary.CompiledClass).%ExistsId("Ens.Util.LookupTableDocument") {
            // only supported in Ensemble 2012.1+
            Write !,!,"Exporting Ensemble Lookup Tables..."
            Set sc = $$$OK
            Set rs = ##class(%ResultSet).%New("Ens.Util.LookupTableDocument:List")
            Do rs.Execute()
            While rs.Next() {
                Set item=rs.Data("name")
                Write "document found: "_ item,!
            }
            Do rs.Close()
            Set rs=""
        }
        If ##class(%Dictionary.CompiledClass).%ExistsId("EnsLib.HL7.SchemaDocument") {
            Write !,!,"Exporting Ensemble HL7 Schemas..."
            Set sc = $$$OK
            Set rs = ##class(%ResultSet).%New("EnsLib.HL7.SchemaDocument:List")
            Do rs.Execute()
            While rs.Next() {
                Set item=rs.Data("name")
                Continue:$listfind($lb("2.1.HL7","2.2.HL7","2.3.HL7","2.4.HL7","2.5.HL7","2.6.HL7","2.7.HL7","2.3.1.HL7","2.5.1.HL7","2.7.1.HL7","ITK.HL7")
                                    ,item)
                Write "document found: "_ item,!
            }
            Do rs.Close()
            Set rs=""
        }
    }
}

Here's a link to the code on GitHub: https://github.com/intersystems-community/code-snippets/blob/master/src/...

00
0 3 439