The NodeVersion must be in the node that has the changes that you want to report. The standard UaNode implementations contain the NodeVersion already, but it seems that it’s not “directly” available, so you need to cast the ObjectsFolder, like this, to initialise the NodeVersion property:

Now you can just add nodes to the folder, for example, with

And the NodeVersion and model change events are triggered automatically.

Or if you want to makes several changes at once, you can use the begin/endModelChange-methods:

Well, in general the support for Views is not very good. The big question to myself is still, what is the proper way to define to which views the different nodes belong to.

So the answer to this one is also “no”.

Hi,

Seems the mention of automatic events without the begin/end was incorrect. Maybe we could implement that in the future, however it would need to be somehow configurable as it might not make sense to make separate event for each change..

There are some quirks on how the ModelChanges are specified and might not be that intuitive. Based on my interpretation of the spec:

1. The events should come from the server object, as per spec (v1.03) Part 3 9.32.3 (ModelChangeEvents) Views:
“…Therefore the only Notifiers which report the
ModelChangeEvents are View Nodes and the Server Object representing the default View.”
The “context” is defined by the affected field of the event. At least I would understand that this means the events are only given by the server object. Also as the event might contain changes from multiple nodes, therefore it would make sense that it is only notified from a central location (while I would argue it would also make sense that it would come from the object itself, if is an object for which references are added/deleted, but it would seem it is not specified so).

2. The affected node can be either the target or the source of the reference. Therefore clients should not assume it is the target. See spec Part 5 12.16 Table 157 for the ‘verb’
ReferenceAdded: “Indicates a Reference has been added. The affected Node may be either a SourceNode or TargetNode.”

For the NodeAdded, NodeDeleted verbs, the spec says 9.32.2:
“There is a correlation between ModelChangeEvents and the NodeVersion Property of Nodes.
Every time a ModelChangeEvent is issued for a Node, its NodeVersion shall be changed, and
every time the NodeVersion is changed, a ModelChangeEvent shall be generated. A Server
shall support both the ModelChangeEvent and the NodeVersion Property or neither, but never
only one of the two mechanisms”

Therefore in order to trigger the NodeAdded, the node must have the property. The nodes created with NodeManagerUaNode.createInstance and NodeBuilder are added to the manager as they are constructed. This also means that unless created by an InstantiationStrategy the node does not contain the property at the time of adding. This should be fixed or e.g. an option added to NodeBuilder which would make the NodeVersion before adding it to the manager. You could workaround this my adding the change manually via NodeManagerTable.getNodeManagerRoot().getModelChangeEvent().addChange(UaNode affectedNode, ModelChangeType… changeTypes) and adding the change manually.

The NodeDeleted should work as expected as it is done before deleting references.

You are correct about the SubscribeToEvents bit. That needs to be fixed. However as per above, you can still only observe ModelChanges from the Server object (which I would argue is anyway the best option as you only need to monitor one node to see all changes).

– Bjarne