Package org.hl7.fhir.r5.model

Class Configuration

java.lang.Object
org.hl7.fhir.r5.model.Configuration
public class Configuration extends Object
This class is created to help implementers deal with a change to the API that was made between versions 0.81 and 0.9 The change is the behaviour of the .getX() where the cardinality of x is 0..1 or 1..1. Before the change, these routines would return null if the object had not previously been assigned, and after the ' change, they will automatically create the object if it had not been assigned (unless the object is polymorphic, in which case, only the type specific getters create the object) When making the transition from the old style to the new style, the main change is that when testing for presence or abssense of the element, instead of doing one of these two: if (obj.getProperty() == null) if (obj.getProperty() != null) you instead do if (!obj.hasProperty()) if (obj.hasProperty()) or else one of these two: if (obj.getProperty().isEmpty()) if (!obj.getProperty().isEmpty()) The only way to sort this out is by finding all these things in the code, and changing them. To help with that, you can set the status field of this class to change how this API behaves. Note: the status value is tied to the way that you program. The intent of this class is to help make developers the transiition to status = 0. The old behaviour is status = 2. To make the transition, set the status code to 1. This way, any time a .getX routine needs to automatically create an object, an exception will be raised instead. The expected use of this is: - set status = 1 - test your code (all paths) - when an exception happens, change the code to use .hasX() or .isEmpty() - when all execution paths don't raise an exception, set status = 0 - start programming to the new style. You can set status = 2 and leave it like that, but this is not compatible with the utilities and validation code, nor with the HAPI code. So everyone shoul make this transition This is a difficult change to make to an API. Most users should engage with it as they migrate from DSTU1 to DSTU2, at the same time as they encounter other changes. This change was made in order to align the two java reference implementations on a common object model, which is an important outcome that justifies making this change to implementers (sorry for any pain caused)
Author:
Grahame