[jdom-interest] interface q (but not the usual one)

[philip.nelson at omniresources.com]

>    I'd rather say:
>       return (List) e.apply(new XPathProcessor(myXPath));
>    or e.apply(customValidator) etc
> 
>    ie have a public Object apply(IElementProcessor processor) 
> method in 
> Element.

Basically, that's the vistor pattern and it was heavily dicussed here.  I
guess I don't us implementing it though the idea has merit.  Easy enough to
do with subclasses though and your own JDOMFactory.


> Secondly, I know I can output to a DOM, but I was wondering about an 
> implementation of DOM that delegates to a JDOM structure; ie 
> create a wrapper 
> round JDOM Document that can be passed to a method expecting an 
> org.w3c.dom.Node but actually manipulates the JDOM document; 
> I've a feeling 
> this would be (a) much work (b) pointless because I'd end up 
> creating lots of 
> little Node/NodeList wrapper objects, and may as well use 
> DOMOutputter. 

It may not be as bad as you think using wrappers, especially if your
application specific need didn't require full compliance to the DOM specs.
Brett's book has a section on this topic with some example code, though it
doesn't implement the DOM classes.

> I also 
> have a requirement to treat some proprietary structures as 
> XML (it's a simple 
> mapping); I guess I would be unable to make JDOM the common 
> API because the 
> interface and implementation are not separated(?) Is there another 
> possibility, other than using DOM or a home grown interface?

Not sure what you mean here.