-
Notifications
You must be signed in to change notification settings - Fork 240
/
TODO
103 lines (69 loc) · 3.2 KB
/
TODO
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
TO DO LIST
==========
By all means help yourself to any of these tasks if you fancy
rolling your sleeves up and doing some development, tuning, testing or
documentation. Any contributions will be greatly received.
Development Tasks
=================
* As suggested by Robert Lebowitz, consider the pretty printing
and OutputFormat to allow very large text nodes to wrap their
text at (say) 80 characters per line.
* Implement a Saxon adapter so that the SAxon XSLT engine can work
natively on top of dom4j.
* implement a Locator Element that maintains the column & line number that
errors may occur on for better debugging.
* implement a proper lazy tree parsing mechanism using the XPP pull parser.
* JDBC ResultSet implementation of an Element so that XPath and XSLT can be
easily done on a JDBC result set.
* Integrate Dennis Sosnoski's XML-Stream work for the default serialization
mechansism
* Support XPath and XSLT patterns in the ElementHandler mechansim
* As suggested by Kesav Kumar Kolla, implement a better, mutable Swing TreeModel
possibly along with an optional document event mechansim
* get the DOM implementation to pass the DOM conformance tests at
http://xmlconf.sourceforge.net/
* a persistent dom4j implementation using XMLDB or some other persistence
mechansim
* investigate the generation of more optimal Element implementations based on
a schema definition, which could still take additional extra schema adjuncts if necessary
but would by default use instance member variables for attributes. e.g.
<customer id="123" name="James" location="UK"/>
could generate
public class CustomerElement extends DefaultElement {
private String id;
private String name;
private String location;
...
}
So the performance benefit of using a bean would remain yet the XPath, XML, SAX benefits would
remain, indeed the use of the 'bean' would be invisible.
Though this might well be similar to using the BeanElement.
Documentation
=============
* make cookbook fit for dom4j 1.2
* adding UML diagramms into cookbook
* add a easier instruction for programmers that starts to use xml and
a instruction for programmers that came form jdom world
* add the test-suite html output created by junit-report to project page.
* improve FOp output for source code samples
Test completed
==============
These features have been developed but require more testing to
determine that they are complete...
* support for setExpandEntities(true) to expand entities, so that
text using "&" could just be treated as a String. So
<foo>A & B</foo>
could be treated as a single Element with a Text node containing a String
"A & B"
* merging adjacent text nodes; use an internal StringBuffer to add multiple
characters() SAX events together.
* whilespace removal option.
Without access to a schema or DTD its hard to do proper whitespace
removal thanks to mixed content, however a simple option for
data-related XML applications, to ignoring all whieespace-only nodes
such that
<customer>
<name>James</name>
</customer>
would only contain 1 child <name> element and not 2 whilespace nodes.
* support of XMLDB native database (org.dom4j.persistence)