|
xmlmapper: java mapping of xml documents |
|
|
xmlmapper: java mapping of xml documents |
|
<Document>
<Title>blabla</Title>
<Item id="1">
</Item>
<Item id="2">
</Item>
</Document>
import java.util.*;
public class Document {
private String text;
private String cDataSection;
private ArrayList titleList;
private ArrayList itemList;
public Document() {
}
public void setText(String text) {
this.text = text;
}
public String getText() {
return text;
}
public void setCDataSection(String cDataSection) {
this.cDataSection = cDataSection;
}
public String getCDataSection() {
return cDataSection;
}
public void setTitleList(ArrayList titleList) {
this.titleList = titleList;
}
public ArrayList getTitleList() {
return titleList;
}
public void setItemList(ArrayList itemList) {
this.itemList = itemList;
}
public ArrayList getItemList() {
return itemList;
}
}
Two other objects are generated on the same principle: Title.java
and Item.java.
Multiple Item objects will be stored in the itemList property of the Document object. The only restriction in this mapping is the text and CDATA fields. Only one text field an one CDATA field is taken in account in order to render the usability easier without having a big lack of functionnality. It is in deed very rare to have to use several text fields in the same XML element.
This package is also able to initialize (dynamically) theses generated classes with the values contained in the xml file, and to write back xml after you assigned new values to the java objects.
The mapping is not based on DTD nor on XML schemes. Therefore,
if you add one new type of element, you need to rebuild the classes. If
you know already you will use some other XML elements, you then have
to declare them in the XML. This mapping choice was done in order to have
a simple mapping package, and also in order not to be limited only to DTD
or only to XML schemes. This particular choice makes you more productive.
With a very big XML file, as it will be entirely mapped into memory,
the resulting application won't be as efficient as if it would use SAX.
A future solution could be to have an EJB mapping. But then it would become
a little bit less easy to use.