Package org.hl7.fhir.dstu3.model
Class Configuration
java.lang.Object
org.hl7.fhir.dstu3.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
-