[jdom-interest] Interface-based JDOM

[Brett McLaughlin]

Tom Bradford wrote:
> 
> Brett McLaughlin wrote:
> > Ahh... so now it becomes clearer. What you are wanting to do is not
> > write a custom implementation of JDOM, but write an implementation of
> > JDOM that extends something you already have.
> 
> I stated this very clearly in my first or second email where I wanted to
> implement dual-interfaced classes.

Then I do apologize, as I missed that. If I had realized that you were
trying to have classes that implemented DOM and JDOM, I would have
spoken up loudly earlier ;-)

> 
> > Your choice of a DOM
> > implementation is very telling. We explicitly prevent the JDOM codebase
> > from implementing DOM, even though newbies occasionally ask for it.
> > That's because JDOM is intended to solve many of DOM's problems, not
> > provide some sort of thin layer over DOM. So by definition, we think
> > what you are wanting to do is a bad idea.
> 
> Pretty bold statement since you're not entirely aware of what the goals
> of our project are.  Overall, we're trying to create a repository where
> any client approach is equally as efficient, whether it be SAX, DOM, or
> JDOM (maybe).  No Node gets graphed or spit out until a client has
> requested it.

No, but I'm aware of the goals of JDOM. In other words, if you need an
implementation of DOM in any form, and will only accept DOM (rather than
alternate, in our opinion better, functionality), then JDOM is probably
not the solution you are looking for. That's sort of brutal, but I hope
shows that we are focused on a specific goal, ease of use. And I argue
that you simply won't have equal efficiency in DOM, JDOM, or SAX. If
that was the case, then we wouldn't need both DOM and JDOM, as they
provide similar functionality. The inefficiency of DOM in certain
situations is why JDOM exists; I submit that if we couldn't overcome
those problems with DOM in 1 year of work, your team won't be able to
solve them either ;-) And I'd also submit that DOM and SAX are
orthogonal in every way - plus, of course, SAX offers no mutability. So
I guess that while I'm not clear on the foundation for your goals, I
still stand on not wanting JDOM to ever implement DOM interfaces.

To reiterate, I'm not questioning your premise, I'm stating that JDOM's
premise is intentionally not to provide DOM implementation
functionality.

> 
> > That makes me even more solid
> > on not wanting interfaces ;-) You can't have JDOM and DOM in the same
> > heap of code and expect to get benefit from JDOM, so your entire point
> > is moot. If for some reason you want the functionality of JDOM but
> > insist on using DOM underneath, you're on your own ... sorry, but the
> > good of the many...
> 
> Actually, our underlying implementation is pretty generalized.  It's
> exposing DOM interfaces in addition to SAX, but the underlying

?? This really doesn't make much sense. You implement DOM, but those
classes don't map to SAX. Why would a Document implement something like
ContentHandler? That really doesn't make sense. SAX builds, DOM
manipulates... maybe I'm missing something here.

> structures are probably closer in their implementation to JDOM than to
> DOM.  The compression system is a pure XML system, not favoring DOM or

That makes sense. That's, in fact, part of the design principle that
went into JDOM.

> SAX.  The point is, I can't leverage any of that code to expose JDOM
> access unless I implement an adapter pattern, which is just as yucky as
> factories.

Finally, we agree on something ;-) I guess if DOM doesn't seem to fit
very well, I would ask why you are using it (at the risk of asking a
question your team is obviously intimately more familiar with than I).

> 
> Why would it be so bad to have code like this:
> 
>    Document doc = new CompressedDocument();
>    doc.setRootElement(new CompressedElement("blah").addContent(new
> JDOMElement("yadda"));

I'm completely OK with this. But why would

CompressedDocument implements Document

be an different in this case from

CompressedDocument extends Document

?

In other words, if you take out the implementing of DOM interfaces, I
don't see why subclassing wouldn't work here.

> 
> On document creation it makes things look different, but on retrieval,
> it would look like this:
> 
>    Document doc = something.getDocument();
>    Element blah = doc.getRootElement();
>    Element yadda = blah.getChild("yadda");

Ditto here as well.

> 
> It would be no different than if I had just subclassed Element and
> Document to create CompressedElement and CompressedDocument, and it
> would still be necessary if I had to create a specialized Element
> implementation. The only thing that would have been different otherwise
> is instead of new JDOMElement("yadda"), it would be new
> Element("yadda").

But that's not what you were arguing; you were arguing that subclassing
did not provide /transparancy/ to the user. Your example, in
implementation or subclassing, does not make the classes used
transparant. To do that, you have to use factories, which is what I
said. So your example is non-transparant, agreed, but so is any example
without factories being put into play, or some other JAXP-analog.

> 
> A Factory approach based on an implementation interface would be cleaner
> from a coding standpoint because you wouldn't have to have knowledge of
> the implementation, but there is power in being able to mix implemented
> classes in a single document (for example, we'd probably only want to
> implement Document and Element),  and there would be no fear in doing so
> if the rule were that any JDOM class implementations must be required to
> internally consume any other classes, which wouldn't really be a problem
> if it were interface-based.  The only thing it would really require is
> exposing setParent and setDocument as part of the interfaces.

And I think we're actually looking at setParent and setDocument as being
abstracted into a root node class or something similar, which would
indirectly solve your problems. Yes, if you use implementations,
factories are required for transparancy. But I'd argue that most
programmers don't like factories that are "in your face"; in other
words, that you have to use to do pretty much anything... just creating
a simple element needs a factory, instead of direct object
instantiation. So I still find myself (and Jason, as we traded voice
mails today) on the side of simplicity and avoiding factories, and
interfaces/implementations.

> 
> One of the major problems with the DOM is that it doesn't provide this
> capability, and you're forced to import Nodes before you append them as
> children, which will almost always cause a deep copy clone of the branch
> if it's not of the same implementation.  If DOM Nodes had

Agreed. Major annoyance ;-)

> setParent/setDocument and the behavior was well-defined as to what an
> implementation should do on appending content, importing wouldn't be
> necessary.

I'd agree as long as there is an additional requirement to have DOM
classes subsume other DOM classes transparantly. But that's not a
current requirement laid out /clearly/, and even so people tend to use
their own classes directly, rather than through the interface, and
therefore introduce dependencies on the impl, not the standard
interfaces. I certainly would fear the same with JDOM, and therefore a
loss of code portability.

> 
> So far, there have been no requests from our users for JDOM support.
> But I like JDOM from an API perspective, and think it would be a nice
> addition to our product.  Hell, I'd even switch to using it exclusively
> if we could get it as tightly integrated as we'd need it to be.

;-) I'd be interested to hear what integration issues you face. For
example, are interfaces needed in your view strictly to integrate with
classes that already implement DOM, is it an implementation of utilities
or your own structure that is needed. Certainly those are all things
that could be more persuasive towards changes or enhancements, rather
than just wanting DOM+JDOM support.

Looking forward to your response, and enjoying the interchange (although
I'm tired of typing ;-) )-

-Brett

> 
> -- Tom