Package org.hl7.fhir.r4.model
Class Configuration
java.lang.Object
org.hl7.fhir.r4.model.Configuration
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
-
Constructor Summary
-
Method Summary
Modifier and TypeMethodDescriptionstatic boolean
static boolean
static boolean
static void
setAcceptInvalidEnums
(boolean value)
-
Constructor Details
-
Configuration
public Configuration()
-
-
Method Details
-
errorOnAutoCreate
-
doAutoCreate
-
isAcceptInvalidEnums
-
setAcceptInvalidEnums
-