The toolkit defines typed data elements in XML files as is the case with other toolkit components. The toolkit types definition file contains the definitions for types and the type's externalizer is able to instantiate the typed data element directly from these definitions. The toolkit also allows typed data element definitions in the data definition file using the <data> tag. This tag enables you to mix typed and non-typed data elements together in the same keyed collection and for typed and non-typed data elements to co-exist in the same context. For more information on external definitions, see Externalizers.
Typed data elements can be instantiated directly from the type definition itself or from a typed data element defined in the data definition file that points to the generic type and possibly overrides some of its descriptors, converters, or validators. The second approach is better because the types definition file then stores only generic types. The data definition file can then define all typed data that the application will use. In summary, the data definition file contains definitions for typed and non-typed data while the types definition file defines the types, which are the entities that describe the business rules for the data elements. The context definition file can have references to the type definitions and self-defined processor files can reference the types defined in the toolkit types definition file or include new type definitions that do not exist in the toolkit types definition file.
New descriptors, converters, and validators defined for an application should implement the validateParams method to validate all parameters defined externally as key-value pairs in the types definition file. The type externalizer invokes this method when it tries to instantiate the entity. As a result, it may help you detect definition errors before the toolkit actually uses instances of these objects.
Additionally, the parameters of converters, and validators can be overridden by another reference data. Usually there is one converter named "default" in the type definition. If there are more than one converter in the type definition, for example, there is another converter named "html", it will differentiate the parameters from these two kinds of converter by addressing conterter name as the prefix of the parameter. For example: "default:pattern", "html:pattern". User can decide which parameters need to override.