I think the answers so far have missed the point. The number of arguments itself is variable. This is handy for things like building a complex SQL statement and set of arguments to pass to %SQL.Statement:%Execute, for example.

The data structure here is an integer-subscripted array with the top node set to the number of elements. (The top node is what's missing in the example above). Subscripts can be missing to leave the argument at that position undefined.

Here's a simple example:

Class DC.Demo.VarArgs
{

ClassMethod Driver()
{
    Do ..PrintN(1,2,3)
    
    Write !!
    For i=1:1:4 {
        Set arg($i(arg)) = i
    }
    Kill arg(3)
    ZWrite arg
    Write !
    Do ..PrintN(arg...)
}

ClassMethod PrintN(pArgs...)
{
    For i=1:1:$Get(pArgs) {
        Write $Get(pArgs(i),"<undefined>"),!
    }
}

}

Output is:

For bootstrap-table, I think the examples on their site are probably more useful than anything I could dig up. https://examples.bootstrap-table.com/#welcomes/large-data.html shows pretty good performance for a large dataset. Tabulator looks nice too though.

In any case it would probably be cleanest to load data via REST rather than rendering everything in the page in an HTML table and then using a library to make the table pretty.

Hi Steve,

We (Application Services - internal applications @ InterSystems) use %UnitTest with some extensions. We have a base Unit Test case that has a "run this test" helper method (among other things), a wrapper around %UnitTest.Manager that makes it easier to run all the tests without deleting them (and with some other features optionally enabled, like test coverage measurement - see a video of my 2018 Global Summit presentation on this here). Our wrapper also loads all of the unit tests before running any, which allows unit tests to extend classes within the unit test root in different packages from their own.

I agree with @Eduard Lebedyuk that %UnitTest meets our needs well aside from the lack of parallelization. A parallel %UnitTest runner would be an interesting project indeed...

We routinely run unit tests via Jenkins CI, report test results in the jUnit format, and also report on code coverage (Cobertura-style) and a complexity/coverage scatter plot.

For automated UI testing, Selenium/Cucumber has worked well for older Zen/CSP UIs. True unit testing of newer UIs (e.g,. Jasmine and Karma for Angular) is handy too.

Disclaimer: I know more about what John is doing than is covered in the post.

It looks like, for the prebuilt themes, Angular Material itself uses Bazel (see introduction at https://angular.io/guide/bazel). The relevant bits are here:

https://github.com/angular/components/blob/master/src/material/prebuilt-themes/BUILD.bazel
https://github.com/angular/components/blob/master/src/material/core/BUILD.bazel
https://github.com/angular/components/blob/master/src/material/BUILD.bazel

I think that's probably the place to start, in terms of Angular 8 best practices.

Fun fact, you can also order by the column by number.

In this case:

select top 5 Description,Category,* from Cinema.Film order by 2

With correct web server configuration to route everything through the CSPGateway, the above example should handle URLs for other resources like that without issue (as long as the content served by the dashboard server has relative links to those endpoints, not absolute) - that's the point of the <base> element.

In my sample use case, it also handles several requests for images and other assets.

I don't think it's totally stupid. We're looking at doing something similar with another technology (JReport).

Here's a code sample to help you get started - just change the port / page / filters / permission checks appropriately.

Class Demo.CSPProxy Extends %CSP.Page
{

Parameter HOST = "127.0.0.1";

Parameter PORT = 8888;

Parameter PAGE = "jinfonet/runReport.jsp";

/// Event handler for <b>PreHTTP</b> event: this is invoked before
/// the HTTP headers for a CSP page have been sent.  All changes to the
/// <class>%CSP.Response</class> class, such as adding cookies, HTTP headers,
/// setting the content type etc. must be made from within the OnPreHTTP() method.
/// Also changes to the state of the CSP application such as changing
/// %session.EndSession or %session.AppTimeout must be made within the OnPreHTTP() method.
/// It is prefered that changes to %session.Preserve are also made in the OnPreHTTP() method
/// as this is more efficient, although it is supported in any section of the page.
/// Return <b>0</b> to prevent <method>OnPage</method> from being called.
ClassMethod OnPreHTTP() As %Boolean [ ServerOnly = 1 ]
{
    Set request = ##class(%Net.HttpRequest).%New()
    Set request.Server = ..#HOST
    Set request.Port = ..#PORT
    
    // TODO: Add other stuff here, like authentication.
    
    Set page = $Piece(%request.CgiEnvs("REQUEST_URI"),"/"_$classname()_".cls/",2)
    If (page = "") {
        Set %base = $classname()_".cls/"_$Piece(..#PAGE,"/",1,*-1)_"/"
        
        // TODO: add query parameters from %request to the URL requested below.
        $$$ThrowOnError(request.Get(..#PAGE))
    } Else {
        Set fullPage = "http://"_..#HOST_":"_..#PORT_"/"_page
        Do ##class(%Net.URLParser).Parse(fullPage,.parts)
        
        // TODO: Better way of checking the requested resource.
        If $Piece($Piece(parts("path"),"/",*),".",2) = "jsp" {
            Set %response.Status = ##class(%CSP.REST).#HTTP403FORBIDDEN
            Quit 0
        }
        $$$ThrowOnError(request.Send(%request.Method,page))
    }
    Set %data = request.HttpResponse.Data
        
    // TODO: Do any other headers matter?
        
    Set %response.Status = request.HttpResponse.StatusCode
    Set %response.ContentType = request.HttpResponse.ContentType
    Quit 1
}

/// Event handler for <b>PAGE</b> event: this is invoked in order to  
/// generate the content of a csp page.
ClassMethod OnPage() As %Status [ ServerOnly = 1 ]
{
    If (%response.ContentType [ "html") && $Data(%base) {
        &html<<base href="#(..EscapeHTML(%base))#">>
        Do %data.OutputToDevice()
    } Else {
        Do %data.OutputToDevice()
    }
    Quit $$$OK
}

}

A few weird things with custom login pages:

CSPSystem needs read permission on the DB containing them. (You'll need to close CSPGateway connections after making this change so that it can reconnect with the right privileges.)

It's specified with the ".cls" extension in the web application configuration, not just the classname.

You should check the SQLCODE from running that statement. If SQLCODE is 100 (no record exists with the specified key), KeyID may not be defined.

See: https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSQL_esql#GSQL_esql_hvars