Message-ID: <1832053102.1429.1425258785568.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1428_1981487533.1425258785568" ------=_Part_1428_1981487533.1425258785568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Please bear with the authors until they finish up with the initial docum= ent (this note will be removed as soon as initial work is done!)=20
This page will host the description and the results of the discussion on=
the implementation details for an extendable Info Architecture.
The current implementation of the ClassInfo and FieldInfo classes and it= s (abstract) superclass XMLClassInfo, respectively, do not provide the poss= ibility/facilities for easy extension to add custom information provided fo= r purposes other than XML and Java unmarshalling from a XML Schema. Hence, = a refactoring of the current *Info class architecture is needed to "pa= ve the way" for custom and/or extendable *Info classes.=20
The purpose of a *Info class is to store the information gathered during= an unmarshalling process of a XML-Schema document containing the definitio= n for various elements and their attributes which will eventually be mapped= to Java Classes. In order to support marshalling of these generated Java c= lasses so-called Descriptors are generated which describe the mapping of th= ese Java classes to XML documents. To support not only the extraction of Ja= va/XML-specific informarion from a XML-Schema, one might want to introduce = a new Schema to support, for example, the mapping from Schema to SQL-based = Database Engines via JDO. This developer would place her meta-information (= which specifies the mapping) in the <appinfo> element of an <annot= ation> element within the base Schema.=20
The following Schema snippet shows an example of an <xs:complexType&g= t; annotated with meta-information to support the mapping between Java and = JDO:=20 =20
A Nature opens the possibility to introduce custom properties which are =
read from <appinfo> elements found in the schema that is handed to th=
e Source Generator. These properties aren't stored by the Natures directly,=
instead they are stored in a HashMap within a ClassInfo. A Nature only spe=
cifies how these properties (contained in the ClassInfo's HashMap) are stor=
ed and assigned. In this sense a Nature represents an external accessor on =
a ClassInfo which is "extended" by custom properties.
In the code snippet above a schema was annotated with JDO-specific infor= mation, e.g. with a <jdo:table> tag. The information contained therei= n should be stored in a corresponding ClassInfo representing the "empl= oyeeType". The following code snippets show how this could be accompli= shed with the implementation suggested above, namely Natures.=20
Therefor we are in need of defining two new interfaces:=20 =20
Along with the introduction of Natures we need to add (at least) two oth= er Interfaces/Classes to model the flow from an annotation (representing so= me nature property) added to a Schema, on to the addition of a property in = the ClassInfo's HashMap and finally to produce some output (JClasses, Descr= iptors) from these Nature-specific properties. These additional interfaces = are the NatureHandler and the NatureProducer.=20
The NatureHandler's purpose is to parse/handle the information obtained = from an <appinfo> element and extract the Nature-specific content the= rein. It then passes this extracted information to a corresponding ClassInf= o via the appropriate Nature implementation.=20
The NatureProducer obtains Nature-specific information stored in the Has= hMap of a ClassInfo and produces the corresponding output, e.g. JClasses, D= escriptors, and so on.