This would be very important to jOOX. From the current implementation, however, I doubt it would be simple to achieve... Is there any particular reason why you're caching all so many wrapper objects instead of lazy creating them when needed?
The DOM Wrapper was written to test the support of Xalan, native Java, and Saxon XPath API's, which happen to be read-only.
Like the jOOX tool, the ideal process would be to make Xalan and Saxon understand native JDOM content, and I am working on both of those libraries...
... but, fundamentally, it was written to support read-only access. Given 'increased' demand for the functionality, I can see reason for considering write-though support, but I am not convinced that's the best solution....
as for the lazy initialization, well, the DOM tree is created in a lazy way, I thought? It runs checKids() on demand.
I can't trace through the logic until later through
Sure, there's no hurry. Nice to know that there's more interaction between various libraries.
You're right, checkKids() lazy initialises your wrappers. But the, I think they are never flushed, i.e. when the underlying model is changed, your wrappers will be stale, unless I'm missing something?
Started looking in to these DOM wrapper issues. This one is 'easy' to close, but I am afraid it is a rejection....
The issues are:
1. The DOM wrappers are only intended to last for the duration of an XPath evaluation, which for other reasons assumes that the 'tree' is constant for the duration.
1. In order to make the tree modifyable while maintaining the DOM wrapper integrity either:
+ the JDOM core classes will need to keep track of all DOM wrapper nodes that wrap them, or
+ the JDOM core classes will need to have a 'modcount' style concept so that each DOM wrapper can inspect the JDOM class to determine whether the DOM wrapper is still valid. This will need to be done the whole way up the tree each time the DOM wrapper is accessed. Neither prospect is appealing....
Fundamentally the DOM wrapper is only useful in limited conditions, and expanding those assumptions would require significant additions to core JDOM classes, which is not easy to justify.
If a different way to solve this problem can be proposed which has little or no impact on the core JDOM class performance or memory footprint then this issue can be reconsidered.
.... why is the markdown formatting failing...?
That's what I had thought. If the intent is to provide read-only wrappers for XPath, etc, where caching wrappers is essential, then write operations are hard to achieve correctly.
The type of wrapper architecture that I had in mind was a stateless one, always calling through to the underlying implementation without any caching. That architecture will make it easy to fully implement org.w3c.dom, while at the same time, being not so performant on certain operations. I guess I'll roll my own implementation subset (I only need Document, Element, and NodeList implementations)
Thanks for your feedback, anyway!