Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Any plans for implementing DOM modification methods? #74

Closed
lukaseder opened this Issue · 4 comments

2 participants

@lukaseder

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?

@rolfl
Collaborator

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

@lukaseder

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?

@rolfl
Collaborator

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...?

@rolfl rolfl closed this
@lukaseder

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.