[jdom-interest] (no subject)

Thu May 29 08:58:45 PDT 2003

Having separate Parent and Child interfaces seems strange because in most
cases (Element is the most common case) the same item is both Parent and
Child. I almost think that you don't want this separation. I.e. have some
interface "Item", that has both  getParent*() and getChild*() which all
return Item(s).

If a particular Item doesn't have a parent, then getParent() should return
null, same for children. The fact that something has or doesn't have a
parent seems more naturally determined by whether getParent() returns null
and not by whether its type is "Child". As even in that case getParent()
could still return null if its unatached. So you'd have to test both
whether its "Child" and whether getParent() is null.

I understand the motivation, that its weird to have Document have
getParent() function and Attribute have a getChild(), but is it really? We
are just saying that those items don't have any parent or children by
having those function return null. I don't see the need to have a type
information indicate whether it can do this, especially if in many cases
you're going to need to cast.

Having two separate Parent/Child intefaces is also very confusing, and I
don't think really helps to treat the JDOM tree as a "generic" tree, if
that was one of the goals. Because you have to do the casts below to walk
the tree. What if you want to walk it down? You'd have to cast the Child
returned by getChild* to Parent, before you can call getChild again?
Not very nice either. And if you start puting getParent() into Parent and
getChild() into Child, than you'll wind up with the same interfaces
anyway.

Which brings me back to my suggestion of having a single "ParentChild"
interface. Call it whatever you want though. I think final cast to
Element/Attribute/Document is fine, but having to cast in chain, whether
walking up or down the tree, is too weird.

just IMO, of course.

-Vadim

PS. I haven't looked at CVS code after B9, so I'm basing the above
comments solely on the mails. Forgive me if I misunderstood anything about
the actual implementation.

On Thu, 29 May 2003, Jason Hunter wrote:

> We put getParent() in Child because children have parents.  Parents
> don't necessarily.  If the call were in Parent, only Document and
> Element would have the call.  We'd probably have to put it in both
> places to enable the method chaining as you'd like.  That's just odd.
>
> Hmm, I'm still thinking we need a method like getParentElement().
> Returns the parent Element or null if root or unattached.  It could be
> added to Child.  Then you could call
> getParentElement().getParentElement()...
>
> Then all b9 getParent() calls can be moved to getParentElement() calls
> in b10.  I think getParent() has to continue returning a Parent just to
> be sensible.
>
> Thoughts?
>
> -jh-
>
>
> Robertson, Jason wrote:
> > So, just wondering, why doesn't Parent have a getParent() method?
> >
> > It seems like this would be reasonable given XML's hierarchical layout, i.e.
> > if you have a parent it's only one parent so getParent() would be
> > unambiguous. Comparatively it doesn't make sense for Child to have something
> > like getChild() since going down the tree is much more complex.
> >
> > In this one tool I've written I have quite a few places where I do, for
> > example
> >
> > getParent().getParent().getParent().getAttribute()
> >
> > and of course I could replace it with XPath, or this:
> >
> > ((Element) ((Child) ((Child)
> > getParent()).getParent()).getParent()).getAttribute()
> >
> > but this looks kinda funny and it just feels like you should be able to
> > string getParent() calls together directly. I guess you'll still have to
> > cast an Element in the end, but one cast is better than several.
> >
> > Jason
> >
> > p.s. I have approx 1 month of jdom-interest locally, and I searched that but
> > didn't find anything. If this has been previously discussed let me know and
> > I'll hit the archives.
> >
> > -----Original Message-----
> > From: Bradley S. Huffman [mailto:hip at a.cs.okstate.edu]
> > Sent: Tuesday, May 27, 2003 4:47 PM
> > To: bob mcwhirter
> > Cc: jdom-interest at jdom.org
> > Subject: Re: [jdom-interest] (no subject)
> >
> >
> > At one time I think I had a patch to jaxen that took care of this. I'll
> > look for it when I get home, make sure it still works, and send it in for
> > jdom-contrib.
> >
> > Brad
> >
> > bob mcwhirter writes:
> >
> >
> >>Yah, fwiw, this broke jaxen and jxpath and their support of JDOM,
> >>according to gump.  I haven't gotten jaxen fixed yet.
> >>
> >>	-bob
> >>
> >>
> >>On Tue, 27 May 2003, Jason Hunter wrote:
> >>
> >>
> >>>>elementMatched(String path, Element e) {
> >>>>  String parentName =
> >
> > e.getParent().getParent().getAttributeValue("name")
> >
> >>;
> >>
> >>>>}
> >>>>
> >>>>This no longer works because getParent() returns a Parent instead of
> >
> > an
> >
> >>>>Element. Is there a way around this?
> >>>
> >>>Cast it?
> >>>
> >>>-jh-
> >>>
> >>>
> >>>_______________________________________________
> >>>To control your jdom-interest membership:
> >>>
> >
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourho
> >
> >>st.com
> >>
> >>--
> >>Bob McWhirter        bob at werken.com
> >>The Werken Company   http://werken.com/
> >>
> >>_______________________________________________
> >>To control your jdom-interest membership:
> >>
> >
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> > t
> >
> >>.com
> >
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
> > t.com
> > _______________________________________________
> > To control your jdom-interest membership:
> > http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
> >
>
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>
>