Hi Otto, well it would be all, if you set it in the build method and single, if you do it individually. And I don't know if I would like a "default-handler" option ... just too much that could go wrong here. If someone sets up a catch-all handler intentionally and in a different part of the application someone registers a field, then the events would disappear from the other.
Could you just post a code snippet, the way I did it to show what you mean? Chris Am 30.10.20, 18:38 schrieb "Otto Fowler" <[email protected]>: sorry if field has handler -> handler() else parentHandler() On October 30, 2020 at 13:37:51, Otto Fowler ([email protected]) wrote: Why not optionally set a handler per field -or- for the whole thing? if field has handlerer On October 30, 2020 at 11:42:36, Christofer Dutz ([email protected]) wrote: Hi all, while doing the refactoring of the field handlers, and cleaning up in the SPI, I did come across the subscription API again. I have to admit I’m not that happy with it. Right now you have to build a subscription request, and with the response to that you can register a handler. Every time I want to use the subscriptions, I have to dig again and find out how to use things. That means for me the API in its current state isn’t very intuitive. Right now in order to subscribe you would do this: final PlcSubscriptionRequest.Builder builder = plcConnection.subscriptionRequestBuilder(); builder.addChangeOfStateField("value-1", “some-address”); builder.addChangeOfStateField("value-2", “some-address”); builder.addChangeOfStateField("value-3", “some-address”); PlcSubscriptionRequest subscriptionRequest = builder.build(); // Execute the subscription response. final PlcSubscriptionResponse subscriptionResponse = subscriptionRequest.execute().get(); // Attach handlers for the incoming data. for (String subscriptionName : subscriptionResponse.getFieldNames()) { final PlcSubscriptionHandle subscriptionHandle = subscriptionResponse.getSubscriptionHandle(subscriptionName); subscriptionHandle.register(new ValueChangeHandler()); } I would propose to change it that you provide the listener when creating the subscription request: final PlcSubscriptionRequest.Builder builder = plcConnection.subscriptionRequestBuilder(); builder.addChangeOfStateField("value-1", “some-address”); builder.addChangeOfStateField("value-2", “some-address”); builder.addChangeOfStateField("value-3", “some-address”); PlcSubscriptionRequest subscriptionRequest = builder.build(new ValueChangeHandler()); // Execute the subscription response. final PlcSubscriptionResponse subscriptionResponse = subscriptionRequest.execute().get(); I know the main difference is that this way you would register the listener to all fields and with the other one you have the chance to attach multiple listners to different sets of fields. I would doubt that this use-case is very common. And you could probably just do the sorting in the handler. Another option would be to have two “build” methods … one which takes a callback handler, and one that doesn’t … we could even just add the new build method and leave the rest unchanged. This would allow both approaches. What do you think? Chris
