[jdom-interest] The JDOM Model, Chapter 15 of Processing XML with Java

[Elliotte Rusty Harold]

At 4:45 PM +0200 5/7/02, Laurent Bihanic wrote:
>Elliotte Rusty Harold wrote:
>>  Sounds complex to me. I prefer a single, more powerful Node 
>>interface. Part of the goal is to remove a lot of the casting and 
>>testing that's necessary now. This just seems to move it to a 
>>different level. Still I suppose it could solve the other half of 
>>the problem, which is the collections API returning Object.
>>
>In all the discussion I had with Jason on that subject, one of 
>Jason's main concerns was not to add "useless" methods to any class. 
>With this in mind, it's impossible to add methods dealing with 
>parent or siblings (because Document does not have any of those), 
>name (because only Element et Attribute have one) or children 
>(because only Document and Element have those).
>

The sibling methods need to return null anyway at the beginning and 
end of the list. Document would just always do that.

As to littering the API, I'm not sure Node has to be an interface. It 
might be simpler as an abstract superclass. No real problem since 
currently all the classes extend Object anyway. (except CDATA, but 
also not a problem). The key idea is to have a common base type. 
Whether that type is an interface or a class is an implementation 
detail.

>After a while I kind of like Jason's vision because it steers JDOM 
>away from having classes displaying a huge number of public methods 
>(such as Swing JTable for example). The API is easier to grasp.
>
>And just like him, I think useless methods are a bad idea. For 
>example, how would you implement getName() on Comment or getParent() 
>on Document?
>

As defined by the XPath 1.0 data model; i.e. the empty string and 
null respectively

>Returning null is bad. IMHO, littering the application code with "if 
>(xxx != null)" statements is worse than requiring the programmer to 
>test and typecast before calling the method. For getParent, how do 
>you distinguish between a null parent (e.g. an element detached from 
>any document) and an invalid call (e.g. getPrent on Document)?

Do you need to do this?

>Finally, using a bitmask allows to flag nodes as implementing 
>commplementary interfaces such as TextContentNode (CDATA, Comment, 
>etc.) or NamedNode (Element and Attribute) for example.
>Personnally, I thing the following code is OK:
>    if ((node.getNodeType() & NamedNode.NAMED_NODE) != 0) {
>       return ((NamedNode)node).getXxx();
>    }
>With Node implementing a hasFeature method, it can even become:
>    if (node.hasFeature(NamedNode.NAMED_NODE_FEATURE)) {
>       return ((NamedNode)node).getXxx();
>    }
>Not worse than any "!= null" test.

It looks a *lot* worse to me. Couldn't you do this without exposing 
those ugly bitfields?  The second option is much preferable, but I 
still suspect this could be cleaned up a lot.

>
>>  I've suggested simply adopting the XPath rules here. The biggest 
>>problem with not having this method is that it's really not 
>>possible to easily get the string content of an element.
>>
>Yes but is the string content of a document meaningful?
>

Yes, very meaningful, as defined by the XPath 1.0 data model.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+