[jdom-interest] API Inertia

[Brett McLaughlin]

> > I think it should be "This is our last
> > chance to make this API what it should be, so big or small,
> > let's change now while we can."
>
> I agree completely. We won't get a second chance to get it right.

Yup. And I hope that the finer points of implementation (in this mail and
others) don't cause us to forget that ;-)

>
> > After over two years of being a Java and XML guy, I think we NEED a
> > commonality in JDOM. This idea that it isn't any better is not valid;
I'm not
> > saying it's better or worse than the current API. I'm saying if I could
go
> back
> > and do JDOM again, there's no way in the world I'd do it without this.
>
> Huh? You've completely lost me here. We should only do things if they make
JDOM
> better, no?

Yup. I'm saying that looking back, I can't imagine why I didn't do this
thing, because I think it would have made JDOM better. However, a year
along, it's harder to think about because of the rather massive impact it
has on so many concepts already in place at JDOM. Make more sense? Sorry, I
get rambling nights sometimes ;-)

>
> > It makes too many things a pain. Traversing a tree, which is a 50 line
> example
> > in DOM (weird structures and all) becomes a tremendous pain in JDOM; I
> > know, because I'm writing the chapters on it.
>
> I haven't tried it in either one, but... why would a Node interface help?
> Assuming you actually want to do something useful with each visited node,
why
> is getting a Node any better than getting an Object? It seems clear that
the
> Node interface would have few (if any!) methods on it, so you'll probably
need
> to cast anyway.

Not if you are trying to do things like serializing. Right now, I'm getting
an Object, but XMLOutputter needs a specific type for output. I refuse to
add output(Object object) to XMLOutputter, but I'd be hapy to see
output(Node node). Then I could get back JDOM Nodes and immediately pass
them into the XMLOutputter output() methods. If you are arguing for ease of
use for the programmer, you certainly have to admit that this is a lot
better than having to get the Object (like from a list from
getMixedContent()), use instanceof to figure out what it is, and then pass
it back into the right XMLOutputter method.

See, that's my problem: we return generic objects, but then require specific
ones. It makes life a pain.

>
> Also - I would imagine that a lot of tree traversing code only cares about
> Elements, no? Node would be irrelevent here. And, if you didn't just care
about
> Elements, which things would you care about? Would you want to visit
Entities?
> Attributes? CDATAs? Strings? It's not clear what should be a Node and what
> shouldn't.

Not at all... I want a lot more than Elements. I want all the content. Yes
to Entities, Attribute, Elements, ProcessingInstructions... And for this
case, I am arguing that Node be the case class for all JDOM objects. Call it
something different if you want (JDOMItem, Item, Construct, whatever), but
I'm not getting into all the addContent() arguments, or marker interface
discussions, here. Just wanting some better type safety. We know more than
simply "this is an Object" so we should let the user in on our extra
knowledge.

>
> > Additionally, with SOAP and things like that, I
> > really am annoyed in having to get an "Object" back over the
> > wire. I can't count on it being something that I can feed to, say,
> > XMLOutputter. How nice would it be to pass a Node, or Item, or whatever,
to
> the
> > print() method of XMLOutputter? Pretty darn sweet.
>
> Again, which classes should be Nodes? XMLOutputter can output an Entity,
but an
> entity doesn't have an XPath value, AFAIK, so the people that want Node
for
> XMLOutputter and the people that want it for getValue() are incompatible.
> There's no single list of what should be a Node and what shouldn't.
Instead,
> you'd need a ton of interfaces to satisfy everyone:

Nope. I think we can clearly indicate the reasoning behind a base
class/interface. I'm not looking to solve the world's problems here. But I
would love a very simple Node (or whatever) interface, with perhaps a method
that provides an Iterator for that Node's children/objects/etc. That could
really make life easy ;-)

-Brett

>
> CanBeOutput
> HasXPathValue
> Parent (e.g. Document and Element)
> DocumentChild (e.g. DocType and Element, but not Attribute)
> ElementChild (e.g. Attribute and Element, but not DocType)
> etc...
>
> And, you'd still have to handle String specially everywhere.
>
> I agree with Jason, that the Node idea is seductive, but when you think
about
> it hard enough, it causes more problems than it solves. XML objects have
too
> many subtle dissimilarities to make a common interface work.
>
> Alex Rosen
> SilverStream Software
> _______________________________________________
> To control your jdom-interest membership:
>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com