Today the top file in dbc2val contain a lot of switches depending on if databroker or val-server is used, like below. This could be refactored to simplify testing. One idea could be to put the databroker/val-server specific code in separate classes, so that we instantiate the "client-class" once and then just call methods on that client class.
Current code:
if self._server_type is ServerType.KUKSA_DATABROKER:
try:
self._provider.update_datapoint(target, value)
except kuksa_client.grpc.VSSClientError:
log.error(f"Error sending {target} to databroker", exc_info=True)
success = False
else:
# Using json.dumps to convert Python values to JSON, for example True -> true
resp=json.loads(kuksa.setValue(target, json.dumps(value)))
if "error" in resp:
log.error(f"Error sending {target} to kuksa-val-server: {resp['error']}")
success = False
Possible new code:
success = self._client.send(target,value)
Some of the code is duplicated for the upcoming ddsidl feeder (#61). We could possibly refactor them to avoid duplication by putting common code in common files.
Today the top file in dbc2val contain a lot of switches depending on if databroker or val-server is used, like below. This could be refactored to simplify testing. One idea could be to put the databroker/val-server specific code in separate classes, so that we instantiate the "client-class" once and then just call methods on that client class.
Current code:
Possible new code:
success = self._client.send(target,value)
Some of the code is duplicated for the upcoming ddsidl feeder (#61). We could possibly refactor them to avoid duplication by putting common code in common files.