core:mode"NO_RESOLVE" (Skip resolving of existing object data)
The core:mode="NO_RESOLVE" control attribute (formerly: core:skipResolve="true") can be set to specify that the object data already existing for a particular node should not be 'resolved' during import.
The purpose of this option is obvious when compared to the standard behaviour:
If the value of attribute core:mode is not set to NO_RESOLVE, the corresponding object data is 'resolved' before the update, i.e. read from the parent object, in order to then apply updates defined by the Import to this data. The imported data is thus merged into the relevant object properties and any features of the object not mentioned in the import remain unchanged.
If the attribute core:mode is set to NO_RESOLVE for a node that refers to a suitable data object within the updated entity, existing detailed data of the object in question is not loaded during import, but instead ignored. In effect, the data object is rebuilt exclusively from the information provided in the import and any features not mentioned in the import disappear.
The option can be used for very simple data objects, such as a single attribute, but also for larger 'aggregates' such as an address in an address attribute with a potentially quite complex internal structure (including other attributes).
The control attribute is, however, not applicable for special parts of the structure, especially the so-called Wrappers, which are used to enumerate elements such as attributes in the <attributes> node or positions in the <lineItems> node.
Example: Updating the value of a date attribute with and without 'resolving' the object
Within an order, the date attribute 'fixed delivery date' (DELIVERY_FIXED) defines a time window for the delivery:
View of the entry form |
Object data of the attribute |
The entry is made in the standard time zone 'Europe/Berlin'. |
<ord:OrderDate id="3651" ... > |
In due course before delivery, the indicated time window should be replaced by a discrete time. An interface provides the corresponding data, i,e, the expected delivery time in the local time zone of the destination.
Delivery time and time zone should be assigned to the date attribute as start and timeZone by the Import. An existing value for end (if any) should be discarded.
The Import shown on the right uses the action UPDATE.
In contrast to default logic, the end value (the 'to' component of the date date range) is therefore deleted by the import. |
<?xml version="1.0" encoding="UTF-8"?> |
Result after the Import:
View of the entry form |
Object data of the attribute |
The time zone appears as a tooltip for the calendar icons. |
<ord:OrderDate id="3651" ... > |
►NOTE◄ Without an indication for the 'To' date the date range element in the input form applies the given 'From' date to both fields. However, for example, the 'To' element could be hidden automatically if its value matches the 'From' date.