In script console, i use print. (displayed on the same window)
In perspective components scripts, I use system.perspective.print (displayed on designer's console)
What is the normal practice, to test script on the gateway event?
if I use timer script - I would need to save project every time, script will run i an loop
should I use message handler, and invoke by sending via util.sendRequest via script console? and return something from script?
Is executing script in script console same as executing it from gateway events?
when I use <loggerName>.info('something') on gateway events - does this create a txt file where you can download share open and scroll, with timestamp? Or is this normally meant for viewing (there is only one place to view it, that is on Gateway->Status Tab)
If you want to test code intended to be used in gateway scope, put it in a project library script function, then create a gateway message handler that will call that function on your behalf (and return its return value). You may need a little bit of "glue" code to extract items from a payload to supply to the library function as if it were being called from the normal source.
Then you can use system.util.sendRequest() in the designer script console, with suitable payload, to call that function indirectly and get the return value into your console.
Use loggers in everything that will run in gateway scope. print just goes to the wrapper log file, which is not very convenient.
Always. Don't use bare print. It has pathological behaviors in some cases.
In gateway or Perspective scope, logged information goes into the gateway logs (!) accessible from the gateway web interface. It also goes to the wrapper log file.
In Designer or Vision Client scopes, logged information is available in the diagnostics window, and is also typically copied to the console.
From the log viewers. Or from the corresponding text output (wrapper log, designer/vision console).
results = system.tag.query(provider, query)
#convert results to dataset
headers = ['tagPath']
rows = []
for r in results:
rows.append([r['fullPath']])
#count number of rows
numOfTags = len(rows)
return system.dataset.toDataSet(headers, rows), numOfTags
My bad, system.util.sendRequest() works perfect in designer as well.
I got error on the input argument which was null.
I am invoking system.tag.query to return 10,000 tags - for users to select a subset.
I found that when table's pager is off, UI will freeze.
It works smooth as butter when pager is on.
How should I do, to allow User able to enable/disable quering/polling of data:
Don't use a script transform. Use a "search" button that calls a project library script with that code, and returns the list. The calling action in the button would assign it to a view custom property, which then drives the table.
The table will update each time they click the search button.
Or something similiar.
You might think script transforms are a convenient place to write your scripts, but they are terrible for controlling data flow, and have more overhead than runScript().
No, I mean avoid using them. If you have an expression binding, and think you need a script transform, just use runScript() within the binding to process the result of the sub-expression. Less overhead.
Any jython that's more than a trivial one or two lines should be in your project script library.
i am following. but I got a weird error.
when using script transform (calling to project script) - I got no error.
But when using runScript(), calling to project script returned error.
I like to understand.
On binding to table component data property.
On the transform, I wrote a script to iterate each row in dataset, add style to row base on the value of cell.
I want to clarify, if I put this script in project library and to be called from transform script.
Isn't it, the script transform will take the same amount of time, wether the script is on project library vs the script on binding transform?
Yes, indistinguishable difference in execution time. But 1:1 execution time is not the reason to use the project library. The reasons are, to start:
Functions in the project library are re-usable. When carefully designed, they can be used in many parts of your application.
Functions in the project library can re-use constants and cached values that are stored in named variables outside the def. This does reduce execution time, as those variables persist from call to call.
Functions in the project library are maintenance-friendly, particularly that they are stored in the filesystem in plain text as code.py, and are therefore very friendly to source code control, like git.
The sort of callout to a library function shown in your comment #13 could be a one-liner, like so:
