i.e. in the designer when you set up a binding, you get that nice little preview that says if it’s a value or an error (and if so what type of error). is that output accessible through scripting (or through public SDK APIs) in any way?
Where are you trying to add this code? Which session is it targeting what do you plan to do with it?
If you accept the binding then you will have the value in the target property. You could setup an onchange event on the property you are binding to to send a message to be handled by script.
Please explain the idea you have, I'm almost certain there will be an alternate method that would be easier.
For expression bindings, with my Integration Toolkit, you can wrap your expression in either debugMe()
or traceMe()
to log exceptions with an MDC tag.
I’m aiming to provide a way for user-generated perspective json to be validated before it’s merged into perspective views programmatically, rather than requiring the user to repeatedly paste in bindings into the designer and see what the preview says/read over the logs.
I can write my own more conservative validator, and will if there’s no other option, but i’d prefer to use what’s already there.
this is quite useful, thanks!
any equivalent for tag, query, prop? (i suppose i could make those all expressions via wrapper)
No, no place to hook in. But those have debug and/or trace log levels that can help.
Assuming that doesn’t change in 8.3 at all?
I've declared my Integration Toolkit production-grade for v8.3. There just wasn't much that broke (RPC serialization, mostly).
If you get access to the current Perspective DesignAdapter
[1] instance (an exercise for the reader) you could in theory hook up your own listener on the event bus:
editorFrame.getAdapter().getEventBus().register(this);
Which would then deliver notifications if you have an appropriately annotated/typed method:
@Subscribe
public void onBindingPreviewValue(BindingEditValueUpdate update) {
Where BindingEditValueUpdate
[2] is the container class describing the data in the binding preview. It's just stringified data at that point, not underlying types (because it's getting sent down from the gateway, and the designer will not have all the same underlying types anyways).