At a Caché level (for namespaces, databases, code, and security), %Installer may be useful; see: http://docs.intersystems.com/cache20152/csp/docbook/DocBook.UI.Page.cls?KEY=GCI_manifest
For Ensemble, there are some additional deployment-related features that might do more for you in terms of settings and lookup tables. See: http://docs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying#EGDV_deployment_overview
It looks like that method only exists in Caché 2015.2.0+. You're probably running on an older version.
(write $zversion?)
Another option, and a caveat about ^%SYS("SystemMode"):
It looks like you're using CCR.* "Environment" is a meaningful term in that context. In namespaces configured for CCR, you can retrieve the environment with $$Env^%buildccr, i.e.:
CCR>w $$Env^%buildccr
BASE
It is possible to have multiple namespaces on the same instance configured as different environments. ^%SYS("SystemMode") is set to the furthest-along environment (of BASE-TEST-LIVE) of any namespace on the instance. That is, if you have a namespace configured as BASE, and configure another one as TEST, ^%SYS("SystemMode") will be changed to TEST - and this is system-wide. Just something to keep in mind.
*CCR (Change Control Record) is an InterSystems in-house application used in sites where InterSystems does implementation work, so this isn't as generally relevant as ^%SYS("SystemMode").
I tend to use %INLIST $ListFromString(?) in cases like this. (Assuming that the list is something like IDs that wouldn't contain commas.)
So, in your example:
<tablePane width="25%" id="testTable" sql="SELECT Id from Tracking_Data.Person WHERE Id %INLIST $ListFromString(?)" showQuery="true">
<parameter/>
</tablePane>
<button caption="Test" onclick="zenThis.composite.testTestTable();"/>
ClientMethod testTestTable() [ Language = javascript ]
{
var table = zenThis.composite.getChildById("testTable");
table.setProperty('parameters', 1, '1,2');
}
This should definitely work. Are you setting the showTabBar property to true for the nested tabGroup? If not, that might explain why nothing is showing up.
I did a project similar to this using %Net.POP3 a few years back (internal ref: ISCX2452), but it's part of a much larger application, so the exact code probably would not be very useful.
The general pattern for using %Net.POP3 is:
Add your own status-checking, try/catch, etc. One important caution: always be careful to clean up the connection when you're done, with either QuitAndRollback or QuitAndCommit. This might be the cause of the error you noted in your last comment - an open connection could be left over from before, blocking additional connections. I think terminating the process will fix this. (I remember this causing all sorts of trouble/confusion on my old project.)
As a side note: if your application/use case is running on Ensemble, EnsLib.EMail.InboundAdapter will do a lot of the hard work for you. See for reference: http://docs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls?K…
This adapter will delete successfully-processed e-mails. From a "syncing" perspective this keeps things simple. If you don't want the messages deleted, a simple workaround might be to subclass EnsLib.EMail.InboundAdapter and %Net.POP3, override DeleteMessage to make it a no-op in the %Net.POP3 subclass, and override the adapter's MailServer property to use your %Net.POP3 subclass. (This would be a bit less messy than overriding OnTask.)
I think SYS.Database (in %SYS), rather than Config.Databases, can accomplish what you want. Particularly, you can open an object representing a database, call its Delete() method, and then call %Save() on it. That seems to have the same effect you're looking for.
Here's a sample class (Demo.Recreate):
Include %occInclude
Class Demo.Recreate
{
ClassMethod Run(pDBDirectory As %String)
{
new $Namespace
zn "%SYS"
try {
//Get the database
set tDB = ##class(SYS.Database).%OpenId(pDBDirectory)
If '$IsObject(tDB) {
$$$ThrowStatus($$$ERROR($$$GeneralError,"Database "_pDBDirectory_" not found."))
}
write !,"Properties of database:",!
zw tDB
write !
//For demonstration purposes: show contents of a global in that DB
for i=1:1:10 {
set ^["^^"_pDBDirectory]demo(i) = i
}
write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!
zw ^["^^"_pDBDirectory]demo
write !
write "Deleting database..."
$$$THROWONERROR(tSC,tDB.Delete())
write " done.",!
write "Recreating database..."
$$$THROWONERROR(tSC,tDB.%Save())
write " done.",!
write !
write !,"Properties of database:",!
zw tDB
write !
//For demonstration purposes: show that contents of global in that DB are gone
write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!
zw ^["^^"_pDBDirectory]demo
zw tDB
} catch anyException {
write anyException.DisplayString(),!
}
}
}
Rather than projecting the property as a table, one option would be to write a custom class query that $orders over the index global, make the column name "KEYS", and make it an [SqlProc]. The SQL would then look like:
It would be nice if there was a generic solution. My first thought was to add this query to an index class (i.e., one that extends %Library.CacheIndex) and generate <query>Fetch/Execute/Close methods for indices that on property(KEYS), but it seems that queries aren't supported as index members. The <indexName><query>Fetch/Execute/Close methods are generated in the persistent class, but there's no actual class query visible from SQL. Maybe %Library.FunctionalIndex would work if you don't mind reinventing the standard bitmap insert/update/delete, but I suspect that you'd end up losing FOR SOME %ELEMENT in this approach, and would need to replace it with %FIND.
I'll send you what I came up with while investigating - maybe it will provide food for thought.