1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Advanced binding features</title>
</head>
<body class="composite">
<div id="bodycol">
<div class="app">
<div class="h3">
<h3><a name="inner-classes">Inner classes</a></h3>
<p>JiBX fully supports working with inner classes, but there are a couple of
potential surprises in how these are handled. First off is the name representation.
The Java source code naming rules treat classes the same as packages, which leads to
some serious ambiguity. For instance, there's no way to determine whether the
class name <code>org.jibx.Abc.Def</code> refers to a class <code>Def</code> in the
package <code>org.jibx.Abc</code> or to an inner class <code>Def</code> of the
class <code>org.jibx.Abc</code>. To avoid this ambiguity, JiBX uses the naming
rules Java applies in generated bytecode, where the character '$' is used as a
separator between a class name and the name of an inner class. So when you're
working with JiBX binding definitions, the class name <code>org.jibx.Abc.Def</code>
always refers to a class <code>Def</code> in the package <code>org.jibx.Abc</code>,
while the class name <code>org.jibx.Abc$Def</code> always refers to an inner class
<code>Def</code> of the class <code>org.jibx.Abc</code>.</p>
<p>The second issue users sometimes run into when using inner classes with JiBX
is that non-static inner classes can't be used directly for unmarshalling. This
is because each non-static inner class instance contains a hidden reference to
the "owning" outer class instance. You can still work with such non-static inner
classes using JiBX, but you need to use a factory method to create an instance
of the class (see <a href="%bindextend%#extmeths">User extension
method hooks</a> for details of working with factory methods).</p>
</div>
<div class="h3">
<h3><a name="enumerations">Enumerations</a></h3>
<p>You can use all types of enumerations with JiBX, including both "official"
Java 5 enum types and various forms of typesafe enumerations which are compatible
with earlier Java versions. Enumerations normally represent simple string values,
so they're represented in the binding definition using a <b>value</b> element
(though if you have an enumeration with complex structure, you can instead use a
<b>structure</b> element just as you would for any other complex class).</p>
<p>Simple Java 5 enum types, where the value to be used in the XML representation
is the same as the enum name, are handled automatically by JiBX. If the value for
the XML representation is different from the enum name, you can use the
<b>enum-value-method</b> attribute of the binding <b>value</b> element (technically
part of the <a href="%bindingattrs%#string">string attribute group</a>) to tell
JiBX which method should be called to obtain the XML representation. The specified
method must take no parameters and return a <code>String</code> value. This
method will be used both when marshalling, to get the text to output, and when
unmarshalling, to see if an enum instance matches the input text (with each enum
value checked in turn until a match is found).</p>
<p>Other types of enumerations require a little more work. Generally the idea of
an enumeration (especially type-safe enumerations) is that only one instance of
the enumeration type is created for each possible value. For JiBX to work with
such an enumeration type for unmarshalling, you need to define a static
deserialization method which takes a text value and returns the corresponding
enumeration instance (see the section <a href="%bindextend%#serdeser"><b>Custom
serializers and deserializers</b></a> on the next page of the tutorial for
details). If the enumeration type defines a <code>toString()</code> method which
returns the text value used in the XML representation, you don't need to specify
anything special for marshalling (since JiBX uses the <code>toString()</code>
method by default for any object being marshalled as a <b>value</b>). If
<code>toString()</code> does <i>not</i> return the value to be used in XML, you
also need to define a serialization method (again, see
<a href="%bindextend%#serdeser"><b>Custom serializers and deserializers</b></a>
for details).</p>
<p>If an enumeration type is used in more than one place in your binding, you
may want to use a <b>format</b> definition for the type. Doing this allows you to
specify the added information in just one place, and then have it used
automatically everywhere that type is referenced. See the
<a href="%bindextend%#extmeths"><b>User extension method hooks</b></a> section
of the next page for details.</p>
</div>
<div class="h3">
<h3><a name="global">Directions and tracking</a></h3>
<p>The <b>binding</b> element that's the root of every binding definition
supports several attributes that control the overall operation of JiBX when
working with that binding. Two of these attributes are worth special mention
as part of this tutorial.</a></p>
<p>The <b>direction</b> attribute lets you define one-way bindings, supporting
either unmarshalling XML to your object classes (<b>direction="input"</b>) or
marshalling your object classes to XML (<b>direction="output"</b>). If you
only need to go in one direction this can simplify your binding definition and
sometimes even your code, since you don't need to define binding attributes
that are only used for the other direction. By default, you always
need to provide all necessary information for going in both directions.</p>
<p>The <b>track-source</b> attribute lets you add source position tracking
when unmarshalling. This can be useful when you want to be able to relate
unmarshalled objects back to particular locations in an input document (as when
reporting errors to a user, for instance). If you use <b>track-source="true"</b>,
the binding compiler will add code to each of your bound object classes to
implement the <code>org.jibx.runtime.ITrackSource</code> interface, and will set
the source position information for each unmarshalled object. You can then
access the source position information (in terms of document name, line number,
and column number) using the methods provided by the interface (though you'll
need to cast your objects to the interface type in order to do this, since the
interface will not be visible at compile time).</p>
<p>See the <a href="%binding%"><binding> element</a> details page for
information on all the available options.</p>
</div>
<div class="h3">
<h3><a name="namespaces">Working with namespaces</a></h3>
<p>Namespaces are an increasingly important part of working with XML. JiBX provides
full support for namespaces, though the <b>namespace</b> element and the <b>ns</b>
attribute for element and attribute names. <a href="#figure18">Figure 18</a>
gives a simple example of a document with two namespaces defined.</p>
<a name="figure18"><b>Figure 18. Working with namespaces</b></a><br>
<img src="images/advanced1.gif" width="572" height="400" alt="Working with namespaces"/>
<p>Here the first <b>namespace</b> element in the binding definition sets the
<i>http://www.sosnoski.com/ns1</i> namespace as the default for elements within
the context of the customer mapping. This is equivalent to a standard default
namespace definition in XML, which is what JiBX creates when marshalling using this
mapping. The portions of the diagram relating to this namespace are highlighted in
blue.</p>
<p>The second <b>namespace</b> element sets the <i>http://www.sosnoski.com/ns2</i>
namespace as the default for both elements and attributes within the context of
the person mapping. This makes the namespace automatically apply to every name
definition unless you override it with a specific namespace using the <b>ns</b>
attribute. The use of this namespace is highlighted in green in the diagram.</p>
<p>If you have namespace definitions that apply to the entire XML document you
can just define these directly as children of the <b>binding</b> element. The
effect of placing a definition there is the same as if it were included separately
within each top-level mapping definition.</p>
<p>See the <a href="%namespace%"><namespace> element</a> details page for
more information on working with namespaces in bindings.</p>
</div>
<div class="h3">
<h3><a name="structuring">Structuring bindings</a></h3>
<p>The <b>include</b> element provides a way to structure
your binding definitions to be more modular and reusable by letting you break
them up into pieces. See the <a href="%include%"><include> element</a>
details page for more information on using this type of modular definition
structure, including how namespaces work in combination with included
bindings.</p>
<p>You should also keep in mind that you can use multiple bindings with a single
set of classes. The only requirement to do this is that all the bindings must be
compiled at the same time - if you compile bindings separately, the last one
compiled will wipe out the information from the earlier bindings. This ability
to work with multiple bindings is an important aspect of JiBX's flexiblity,
allowing such uses as working with multiple versions of XML documents in a
single set of Java classes (unlike other frameworks, which would generally
require a separate set of classes for each version of the documents).</p>
<div><p align="center"><a href="%bindextend%"><b>Next: Method hooks for extending JiBX</b></a></p></div>
</div>
</div>
</div>
</body>
</html>
|
