Hi Simcha,

you can easily retrieve the data that you are using in your layout (AlerTList in your case), by calling the function getSourceData() on your documentView component. Assuming the id of your documentView is 'mainView', the following code sample should work in your environment:

var view = zen('mainView');

var data = view.getSourceData();

console.log(data.AlerTList);

HTH,

Stefan

Hi Jules,

which Perl distribution are you using? We do support the ActiveState Perl distribution. Also, ensure that you are using a bitness version that matches the bitness of your Caché instance (64-bit in your case).

HTH,

Stefan

Hi Lucas,

I suggest you open a WRC case with Support so that we can look into the details of what is happening here. This may be a problem specific to the environment.

Regards,

Stefan

Embedding a JLNP file in a CSP page is the same as in a plain HTML page. You have to embed and load the JLNP file using something like the following snippet:

<script src="https://www.java.com/js/deployJava.js"></script>
<script>
    var attributes = {} ;
    <!-- Base64 encoded string truncated below for readability -->
    var parameters = {jnlp_href: 'your_applet.jnlp',
        jnlp_embedded: 'PCEtLSANCi8qDQogKiBDb ... bmxwPg=='
    } ;
    deployJava.runApplet(attributes, parameters, '1.8');
</script>

In order to figure out the value for the jnlp_embedded parameter you have to base64 encode the contents of your JNLP file. The JNLP file has to be accessible from the relative link provided by the parameter jnlp_href.

This tutorial explains how to embed JNLP files:

http://docs.oracle.com/javase/tutorial/deployment/deploymentInDepth/emb…

Interesting thought Sebastian.

We haven't run dedicated benchmarks on this topic, but I can provide some guidelines.  You have to acknowledge that creating a dynamic object or a dynamic array is the most expensive part of your code style compared to just using plain variables. You are instantiating an object.

If you run a simple benchmark like the following you can observe a difference:

ClassMethod TestAll()
{
    set iterations = 1000000
    
    set start = $P($H,",",2)
    for i=1:1:iterations {
        do ..TestDynamicObject()
    }
    set time = $P($H,",",2) - start
    w "Dynamic Object test case took "_time_" seconds",!
    
    set start = $P($H,",",2)
    for i=1:1:iterations {
        do ..TestVariables()
    }
    set time = $P($H,",",2) - start
    w "Variable test case took "_time_" seconds",!
}

ClassMethod TestDynamicObject()
{
    set do = {}
    set do.setting1 = "value"
    set do.setting2 = "value"
    set do.setting3 = "value"
    set do.setting4 = "value"
    set do.setting5 = "value"
    set do.setting6 = "value"
    set do.setting7 = "value"
    set do.setting8 = "value"
    set do.setting9 = "value"
    set do.setting10 = "value"
}

ClassMethod TestVariables()
{
    set setting1 = "value"
    set setting2 = "value"
    set setting3 = "value"
    set setting4 = "value"
    set setting5 = "value"
    set setting6 = "value"
    set setting7 = "value"
    set setting8 = "value"
    set setting9 = "value"
    set setting10 = "value"
}

The result on my local machine looks like this:

USER>do ##class(User.DOAPerf).TestAll()
Dynamic Object test case took 13 seconds
Variable test case took 0 seconds

So there is a significant difference IF your code is called often enough to actually make the overhead noticeable. In the above example I called each method 1 million times. If your code is not called that often you will not observe a difference.

As a general advice I would not nest the dynamic objects or dynamic arrays when used as you describe it, as this increases the number of object creations.

Long story short: Stick with variables in performance-critical parts of your application. In other parts of your application you can use dynamic objects or dynamic arrays as temporary objects for sure, just make sure you only nest them when absolutely required. Passing complex structures between method calls with dynamic objects can be very elegant.

HTH,

Stefan

While it is true that Generics are not supported by the Java Gateway I would like to provide a little more guidance on why that is the case and how to deal with this not uncommon situation.

The Java Gateway (and the dotNet Gateway by the way) allow you to interface between ObjectScript and another language environment and obviously there are concepts in one language foreign to the other. Our approach to the Gateways is to support basic structures and concepts which are similar in both languages or easily translated between them. A "complete" approach would not only take very long to implement, would be hard to verify for correctness and because of the rules you had to apply not easy to understand. It would defeat the basic rule "power through simplicity".

Generics is a case which is not easily mapped and therefore not supported. Of course you can come up with ideas how to support such a concept with what the server-side environment has to offer, but keep in mind what I wrote above.

 Every time you encounter such a situation you find yourself in a situation where the Java API you would like to call from our side of the fence is too complex and properly includes functionality you don't want to interact with in its entirety.

The Facade pattern allows you to easily work around this challenge. Build a basic API around the functionality you want to interact with on the Java side and import your handwritten entry point. This makes the interface much more manageable for the gateway and all the participating parties as the contract between Java and ObjectScript is very clear with this pattern.

Hope that helps,

Stefan 

Hi Tosh,

it seems your path is not correctly setup as the process is not able to identify the underlying C binding libraries. I assume you are using the 64-bit version of Python. Also I want to point out that we currently only support Python 3 up to version 3.3 as later versions introduced quite significant changes in string handling. We are working on supporting versions beyond 3.3 at the moment.

HTH,

Stefan

Hi Akshay,

this functionality was teased at Virtual Summit but is not released yet. Also, this will be an IRIS for Health feature, as the DTL Generator works on inbound and outbound pairs of HL7 messages.

Best,

Stefan