[jdom-interest] Abstracting interface to JDOM nodes.

Trebor A. Rude trebor at bwn.net
Sat Aug 26 11:46:06 PDT 2000


On Sat, 26 Aug 2000, Elliotte Rusty Harold wrote:
>At 10:08 AM -0600 8/26/00, Trebor A. Rude wrote:
>>
>>XMLOutputter xmlWriter = new XMLOutputter("", false);
>>ByteArrayOutputStream byteRep = new ByteArrayOutputStream();
>>xmlWriter.output(someDocument, byteRep);
>>String stringRep = byteRep.toString();
>
>It will be simpler and more or less look like this:
>
>XMLOutputter xmlWriter = new XMLOutputter("", false);
>String s1 = xmlWriter.serialize(document);
>String s2 = xmlWriter.serialize(element);
>String s3 = xmlWriter.serialize(attribute);

	This is much better, thanks for the clarification. If there's anything I 
can do to help, please let me know.

>etc.
>However, that functionality isn't there yet. Currently, I've stopped
>working on this part of XMLOutputter until we can resolve the
>question of where to put the configuration options. Also, before
>anybody does anything else with XMLOutputter I'd like to get the new
>Namespace code and fixes rolled in.

	Can you give me a pointer as to where in the archives to look for 
questions you're trying to resolve?

>>>2. You don't need a common interface. instanceof works just fine for
>>>this use case.
>>
>>	So I'd have to have a separate instanceof test for all the different
>>types of nodes? That seems terribly inelegant to me. Interfaces were
>>designed to prevent just that kind of thing.
>
>It doesn't seem all that inelegant to me, and I disagree that
>interfaces were designed to handle this case. Interfaces were
>designed to handle the case when you genuinely do not know in advance
>what types you might deal with. Here we have a very finite, small
>list of possible types that will not change.  The reason there's no
>Node interface in JDOM is two-fold:
>
>1. Strings are used instead of Text nodes and we can't change the String
> class.
>
>2. There simply isn't that much common functionality shared between
>the different node types. For instance, only Document and Element
>have children so you shouldn't put a getChildren() method in a Node
>interface.

	Fair enough.  A matter of taste, I suppose. I guess for some reason I 
thought there would be a good number of common operations.

-- 
Trebor A. Rude
trebor at bwn.net
Registered Linux User #89308
http://counter.li.org/



More information about the jdom-interest mailing list