New post
AllAccepted answers
Timothy Leavitt · Jul 19, 2021

The right way to describe a list of a particular type of object is:

ClassMethod myMethod() As %ListOfObjects(ELEMENTTYPE="MyPackage.MyClass")

This is most relevant from the perspective of XML projections - e.g., web services. You can also define a subclass of %ListOfObjects with the ELEMENTTYPE parameter overridden for reuse. See https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GX...

Timothy Leavitt · Jul 7, 2021

One note - many use cases that call for a composite primary key in a typical boring database would be good use cases for a parent-child relationship in IRIS. This provides nicer features from an object/SQL perspective (e.g., using arrow syntax / implicit joins instead of explicit joins on the composite key fields). See: https://docs.intersystems.com/irisforhealthlatest/csp/docbook/Doc.View.c...

Timothy Leavitt · Jul 7, 2021

@Yuri Marx there's actually a separate "API Security Top 10" which is particularly relevant for REST APIs and modern web applications: https://owasp.org/www-project-api-security/

API4, API9, and API10 are all good IAM use cases; for the others, I'd recommend looking at https://github.com/intersystems/apps-rest for a security-first generic REST API implementation.

Timothy Leavitt · Jun 23, 2021

I'd expect that to work provided the id (not name) of the combobox/dataCombo is 'MyCombo'. e.g., this works fine:

Class DC.Demo.FindElement Extends %ZEN.Component.page
{

XData Contents [ XMLNamespace = "http://www.intersystems.com/zen" ]
{
<page xmlns="http://www.intersystems.com/zen">
<form>
<tabGroup showTabBar="true">
<tab caption="Tab One">
<combobox id="MyCombo" editable="true" />
</tab>
<tab caption="Tab Two">
</tab>
</tabGroup>
</form>
<button onclick="zenPage.alertComboValue()" />
</page>
}

ClientMethod alertComboValue() [ Language = javascript ]
{
    alert(zen('MyCombo').findElement('input').value);
}

}
Timothy Leavitt · Jun 10, 2021

This is a little messy and I'm going to report part of the answer as a bug internally. But regardless, here's one way to make it work - in short, have all of the things that could be listed as a recipient extend a common parent class, and in that class override %JSONNew to detect which type it is.

Class DC.Demo.Container Extends (%RegisteredObject, %JSON.Adaptor)
{
Property recipient As DC.Demo.Recipient;
ClassMethod Demo()
{
    for json = {"recipient":{"dob":"2021-06-10"}}, {"recipient":{"reference":"foo"}} {
        set inst = ..%New()
        do inst.%JSONImport(json)
        write !,json.%ToJSON(),!,$classname(inst.recipient),!
    }
}
}

Class DC.Demo.Recipient Extends (%RegisteredObject, %JSON.Adaptor)
{
/// Get an instance of an JSON enabled class.<br><br>
/// 
/// You may override this method to do custom processing (such as initializing
/// the object instance) before returning an instance of this class.
/// However, this method should not be called directly from user code.<br>
/// Arguments:<br>
///     dynamicObject is the dynamic object with thee values to be assigned to the new object.<br>
///     containerOref is the containing object instance when called from JSONImport.
ClassMethod %JSONNew(dynamicObject As %DynamicObject, containerOref As %RegisteredObject = "") As %RegisteredObject
{
    // This is weird: shouldn't need to reference .recipient here
    if dynamicObject.recipient.%IsDefined("dob") {
        quit ##class(DC.Demo.Patient).%New()
    } elseif dynamicObject.recipient.%IsDefined("reference") {
        quit ##class(DC.Demo.Reference).%New()
    } else {
        quit ..%New()
    }
}
}

Class DC.Demo.Reference Extends DC.Demo.Recipient
{
Property reference As %String;
}

Class DC.Demo.Patient Extends DC.Demo.Recipient
{
Property dob As %Date;
}

Output is:

 d ##class(DC.Demo.Container).Demo()
{"recipient":{"dob":"2021-06-10"}}
DC.Demo.Patient
{"recipient":{"reference":"foo"}}
DC.Demo.Reference

Only problem is, %JSONNew (as advertised in class reference documentation) should get the %DynamicObject representing the object itself, not the parent %DynamicObject. This would only really work if each type is used in exactly one context like this, which seems unlikely.

Timothy Leavitt · May 19, 2021

First off, it's generally best to avoid xecute. ;)

In the first case, routine is private (it isn't visible in the xecute stack frame). In the second, it's public, so it is visible there.

You could get the best of both worlds with:

ClassMethod Run()
{
   set routine="variable"
   set call="(routine) write routine,!"
   xecute (call, routine)
   quit
}

For more info see https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...

Timothy Leavitt · Apr 28, 2021

Perhaps pass the object ID into something like:

Query GetInfo(refId As %String) As %SQLQuery(CONTAINID = 1, ROWSPEC = "IdList:%String,IdProcess:%String,Duration:%String")
{
    SELECT list.IdList, list.IdProcess, list.Duration
    FROM Kurro.MyClass list
    JOIN Kurro.MyClass ref on ref.ID = :refId
    AND ref.KeyProcess = list.KeyProcess
    AND ref.CodeSpecialist = list.CodeSpecialist
    AND ref.CodeProvider = list.CodeProvider
    AND ref.CodeCenter = list.CodeCenter
    AND ref.Date = list.Date
}