The DomainConverter interface is the one most likely to be used for customizations. It defines several simple methods that perform the main data conversion operations. They are listed as follows. For more information see the Cúram JavaDoc documentation for this interface.
This method is used to format the given object to a string representation.
This method is used to parse the given string representation into an object.
This method is used to validate an object according to the domain-specific constraints. It may throw an exception if the object is invalid, but does not modify the object or return any value.
This method returns the class object that indicates the required type of the object that is passed to the other converter methods or returned by them.
This method is used to get the locale to be used when formatting or parsing generic values. This should be the "en_US" locale and you should not change this value; it does not matter if this locale is not otherwise used in your application.
This method is used to format the given object to a generic string representation.
This method is used to parse the given generic string representation into an object of the appropriate type for the associated domain.
As described above, the formatGeneric and parseGeneric methods are similar to the format and parse methods, but they are used when converting the values of the domain definition options entered in the UML model by developers or of values embedded in XML-based data. Domain definition option values, for example: maximum date values, minimum size values, or regular expressions used for pattern matching; are extracted from the UML model at build-time and are parsed to their Java object representations at run-time, so that they can be used when validating data entered by a user. A similar process is used when extracting values from XML data returned from the application server and when constructing XML data before it is returned to the application server. The default implementations of the formatGeneric and parseGeneric methods are sufficient for all purposes (see Generic Parse Operations for information on protecting the generic parse operation from side-effects).
It is by implementing these converter methods or overriding existing implementations of them that most customizations are performed. The simple method signatures disguise the fact that, via the inherited DomainPlugIn interface, each method has access to the active user's locale and the full domain information if necessary.
Implementations of the pre-parse and pre-validate operations are provided for all of the root domains in the Cúram application. As these operations are controlled completely by the setting of domain definition options in the UML model, there is rarely any need to customize them programmatically. However, there are circumstances where custom error messages are required, so you may need to "wrap" these operations to intercept and replace error messages (this is described in detail in Custom Error Reporting). These operations are defined on a separate ClientDomainConverter interface. They are listed as follows. For more information about these methods, see the Cúram JavaDoc documentation for this interface.
This method prepares a string for parsing by applying the relevant domain options. For example, the string may have whitespace removed or compressed, or may be converted to upper-case. The locale is used for the conversion to upper-case, if that is required.
This method performs the standard validation checks that are controlled by the domain options specified in the UML model. The checks include the maximum and minimum size, the maximum and minimum value, and the matching of a pattern. The specific data-type of the object will determine which of these checks are appropriate. The options and comparator are available from the domain.
Access to the ClientDomainConverter interface is only supported for the purposes of error message interception. However, as all converter plug-ins created for use by the client infrastructure must implement this interface, you must sub-class an existing converter plug-in class (or abstract class) when creating custom converter plug-ins to inherit an appropriate implementation.